Thanks for the help guys, I'm glad my instincts were correct and I wasn't screwing up something really basic.

More strangeness:

WORKS:

Code:

#define PACK_STYLE 0

#if PACK_STYLE == 0
  const byte BARGRAPH_STANDBY = 1; // Safety on
  const byte BARGRAPH_IDLE = 2; // Ready to fire
  const byte BARGRAPH_FIRE = 3; // Black button
  const byte BARGRAPH_ALTFIRE = 4; // Red button
#endif

WORKS:

Code:

#define PACK_STYLE 1

#if PACK_STYLE == 1
  const byte BARGRAPH_STANDBY = 2; // Safety on
  const byte BARGRAPH_IDLE = 1; // Ready to fire
  const byte BARGRAPH_FIRE = 3; // Black button
  const byte BARGRAPH_ALTFIRE = 4; // Red button
#endif

DOESN'T WORK:

Code:

#define PACK_STYLE 1

#if PACK_STYLE == 0
  const byte BARGRAPH_STANDBY = 1; // Safety on
  const byte BARGRAPH_IDLE = 2; // Ready to fire
  const byte BARGRAPH_FIRE = 3; // Black button
  const byte BARGRAPH_ALTFIRE = 4; // Red button
#endif

#if PACK_STYLE == 1
  const byte BARGRAPH_STANDBY = 2; // Safety on
  const byte BARGRAPH_IDLE = 1; // Ready to fire
  const byte BARGRAPH_FIRE = 3; // Black button
  const byte BARGRAPH_ALTFIRE = 4; // Red button
#endif

What happens when you place the directive:

Code:

#include <arduino.h>

at the top of your source file?

No change.

The error is:
"mapToPort() was not declared in this scope"

That being a function in one of my tabs in the IDE.

The bulk of the code is much too large to post.  And since I changed he name of the #define to something that can't possibly exist elsewhere the bug has to either be in that block of code there or it is related to how the IDE automatically includes functions when you use multiple tabs.  I'm thinking it's the latter.

I tried changing the name of the define, and the format of the #if block and I still have the same problem:

Code:

#define PACK_STYLE 1

// STYLE 0 = normal, 1 = swapped idle and standby (PAT), 2 = solid when in standby, standby animation otherwise
// STYLE 2 also disables the overheat and overload functions, as well as venting, and heating up, and replaces the shotgun with the normal strobe animation but with alternative sound effects.

#if PACK_STYLE == 0
  const byte BARGRAPH_STANDBY = 1; // Safety on
  const byte BARGRAPH_IDLE = 2; // Ready to fire
  const byte BARGRAPH_FIRE = 3; // Black button
  const byte BARGRAPH_ALTFIRE = 4; // Red button
#else
  #if PACK_STYLE == 1
    const byte BARGRAPH_STANDBY = 2; // Safety on
    const byte BARGRAPH_IDLE = 1; // Ready to fire
    const byte BARGRAPH_FIRE = 3; // Black button
    const byte BARGRAPH_ALTFIRE = 4; // Red button
  #else
    #if PACK_STYLE == 2
  const byte BARGRAPH_STANDBY = 9; // Safety on
  const byte BARGRAPH_IDLE = 1; // Ready to fire
  const byte BARGRAPH_FIRE = 1; // Black button
  const byte BARGRAPH_ALTFIRE = 1; // Red button
    #endif
  #endif
#endif

I'm using some #defines in my program, and having not used them a lot in the past, I'm not really familiar with all their quirks, but I'm getting a weird error and I think I'm using them correctly here, so I don't know what might be going on.

Here's the code:

Code:

#define STYLE 2

// STYLE 0 = normal, 1 = swapped idle and standby (PAT), 2 = solid when in standby, standby animation otherwise
// STYLE 2 also disables the overheat and overload functions, as well as venting, and heating up, and replaces the shotgun with the normal strobe animation but with alternative sound effects.

#if STYLE == 0
  const byte BARGRAPH_STANDBY = 1; // Safety on
  const byte BARGRAPH_IDLE = 2; // Ready to fire
  const byte BARGRAPH_FIRE = 3; // Black button
  const byte BARGRAPH_ALTFIRE = 4; // Red button
#elif STYLE == 1
  const byte BARGRAPH_STANDBY = 2; // Safety on
  const byte BARGRAPH_IDLE = 1; // Ready to fire
  const byte BARGRAPH_FIRE = 3; // Black button
  const byte BARGRAPH_ALTFIRE = 4; // Red button
#elif STYLE == 2
  const byte BARGRAPH_STANDBY = 9; // Safety on
  const byte BARGRAPH_IDLE = 1; // Ready to fire
  const byte BARGRAPH_FIRE = 1; // Black button
  const byte BARGRAPH_ALTFIRE = 1; // Red button
#endif

Seems fairly straightforward, and it compiles fine if STYLE = 0, but as soon as I set STYLE to anything else, I get errors that other functions in my code are undefined.  My project has multiple tabs and I suspect what is happening here has something to do with how the Arduino IDE combines source files, but other than that I have no idea what might be wrong.  I suppose my next step will be to replace those with #else and #if statements to see if that corrects the problem, but I'd still like to know what's up with the #elif.

It's the top part of the connector, it is what pushes down on the top part of the ribbon cable and clips in.

All the IDC connectors I've seen have semicircular indents on that portion of the connector which wrap around the wires.  That looks like it might be some kind of tape you have to peel the backing off of.  Or perhaps it's just some cardboard which is there to prevent the connector from seating in place during transit?  I think I got some connectors once with something like that.

And they're $4 each

Is that expensive to you?

When I need to make or get 50 of these cables manufactured and I'm working on a shoestring budget?  Yes.

Anyway, thanks for the help guys. I determined that it was cheaper and easier to just get the cables manufactured. 

This was what I was planning to do originally on one end of the cable:


But for what it would have cost me for the 300' of ribbon cable and IDC connectors (the second rainbow cable was another $100 on top of that), I was able to get 375' of cable with crimp connectors on each end plus housings, so I can have the cable terminate with the proper connections instead of doing a half-assed job.  I was only considering the IDC connectors because the other option would have been crimping 1600 connectors by hand myself, and aside from having no interest in doing that, I was also pressed for time.

This is what the cable is for by the way.  It's a 7.5' long cable which extends all the switch, strobe, and vibration motor cables from the gun to the backpack:
http://www.mightymicrocontroller.com/kits/proton-pack/

In the videos, the kit is installed in the gun, but many people wanted to be able to install it in the backpack so as to have more room in the gun for tip extension mechanisms and speakers and the like. 

The only one I found there was this one:
http://www.newark.com/3m/4616-6001/wire-board-connector-plug-16pos/dp/87F4001

And they're $4 each, and there's some kinda weird strip on the top half where the indents should be that concerns me.

I was hoping to find the black ones somewhere, the gray 3M ones are all fairly expensive.  I'd rather not spend $100+ on connectors.

I need a 16 pos 2.54mm IDC connector like this:
(The one with the pins in it.)



Anyone know where I can find those?  I've searched Digikey and Mouser and Newark but haven't had much luck.  All the ones I've found have latches and are really expensive ($5-$10 each), or the minimum order quantity is 1000 and I need more like 30. 

The intent here is to plug some jumpers into the ribbon cable.  I realize I could get some long pins and shove them in the socket, but I figured it would be cheaper and simpler to just use the male version of the connector in the first place.

I'd also like to get a 6 pos and 10 pos version of the connector, but I need both if I do that and I doubt I'm going to find a 6 pos version of this anywhere.

You have a large pulsed current flowing from the battery to the LED boards, via the microcontroller board. Because of the resistance and inductance of the power supply lines, this means that the ground on the microcontroller board carries a small pulsed voltage relative to the battery negative terminal.

I don't understand.  Is it because the ground plane and wires act kind of like a capacitor as power flows in and the battery is unable to discharge them back to 0V quickly enough that the ground potential of the board fluctuates as the LED modules draw power?  Is that why you suggested I use larger wires?  Because with less resistance the battery will be able to pull the ground plane back down to 0V (relative to the battery ground) more quickly?
 

The transformer fixes the problem because you feed the difference between line output and microprocessor ground to the primary (thereby cancelling out that small pulsed voltage) and this gets reflected at the secondary.

Makes sense. 

So am I right in assuming that the reason putting a cap in series with the RCA's ground pin didn't work, was because the fluctuations on the ground were AC in nature, and could pass right through the cap? 

1. You really should provide adequate power supply bypassing on the LED boards. Without this, your boards may also generate RFI. I think you need at least 1000uF between +5V (the positive supply to the LEDs) and the ground pin of the TLC5947. 2200uF or 4700uF would be better. An inductor in series with the incoming +5V on the LED board (as discussed earlier) would be the next step.

I will, when I have a new batch of boards made.

2. Include a small PCB-mounting audio isolation transformer on the microcontroller board.

Not gonna happen. 

1. The boards need to be really small.  I'd never be able to fit a transformer on there and still fit the board where it needs to go.  (Handheld costume props.)

2. All audio transformers filter out some frequencies, but most I've looked at don't provide data on what frequencies they're good for, and I don't know how to calculate that.   

3. They tend to be fairly expensive and many aren't stocked in large quantities on Digikey.

4.  I don't want to stick this big ugly thing on my beautiful surface mount board:



That's one of the cheaper ones available in large quantiies, and one of the few that actually provides data on the frequencies it handles but it's still too big, and ugly, and it only handles down to 100hz which means I'd lose all the bass in my audio, so that's no good.

As a last resort I could make my own ground loop isolator cables with a custom PCB and heat shrink the thing.  That wouldn't be too bad but still, a costly solution, labor intensive, and I'd lose frequencies I want to keep.

 

3. In the diagram in your original post, you have a ground connection to R11, R12 and JP7. If you choose not to include a transformer, then make provision on your board to separate this ground from the main ground on the board, with a jumper connecting them together. When using a common supply, remove the jumper. This way, the voltage divider will be referenced to the amplifier input ground instead of the microcontroller ground, so at the same time as reducing the signal voltage, the divider will reduce the noise voltage passed to the amplifier. Removing the jumper will eliminate the ground loop too.

This sounds like an excellent solution and is something I may be able to try out with a little surgery on one of my boards. 

I wish I didn't need to use a jumper to do it...  Don't really have room for a switc.  Perhaps I could just require the user to tie the board and amp grounds together at the power input if they choose to run them on separate power sources?  95% of them will choose to run them off the same battery, so if I could get away without adding a jumper to the board that would be nice.

4. Use thick wires between the microcontroller board and the battery (to reduce resistance), and ensure the power and ground conductors are in the same cable, or twisted around each other (to minimize the area they enclose and thereby minimize the inductance).

I'll make that suggestion to my customers, but I have no control over what they do there.  The first guy I gave a board to connected the amp up with like 28 AWG wire.


Thanks for all the suggestions.  I think I have a little better understanding of what's going on now at least and I can try out tying those grounds together on the line out and see how that works.  If that works that will be perfect.

I think you're beginning to learn a painful lesson on why you don't produce a PCB in large numbers until you've had a chance to run it through the wringer for a while.  ;-)

Well I didn't really have a choice. 

I raised the $16K to produce the boards in May of last year (actually $14K since Kickstarter and Amazon took a chunk) and then I realized my original design wasn't going to cut it and redesigned the whole thing virtually from scratch, upgrading the 328P to the 1284P, increasing the available IO ports, changing the power LED to an indicator LED, redesigning the audio circuit to provide better isolation from noise in the power and ground planes (apparently I didn't do a good enough job), moving all the LED drivers off the main board (driven by the realization that with a proton pack, at least one on the board would end up being wasted, and it was more efficient to create modules that could allow ribbon cables to be plugged in), and finally just before shipping, I had to remove the voltage regulator from the board and replace it with the mosfet because I realized I'd screwed up the power dissipation calculations and the regulator was going to melt the board to slag.

I stupidly assumed that if I followed the recommended layout for the TLC5947 exactly that that would provide adequate noise suppression. And I didn't encounter anyone who'd mentioned having this sort of problem with them.  And as for the audio circuit, I did the same, following the schematic, and looking at how others designed their line outs.  I tried my best to isolate that portion of the circuit from noise, but information on how to properly isolate the audio portion of a circuit is hard to come by.

Anyway, I finished the redesign at the end of September and many folks were expecting the boards for Halloween and I thought maybe I could still put together something in that time, but obviously that didn't happen.  Programming them and working out the kinks with the audio by moving the LED drivers to their own data bus, and then getting an SD card based bootloader to work took several more months, and I've finally just started to ship them.  Yes, I've had to ship them with the audio problem.  My customers are willing to purchase a  ground loop isolator, but not willing to wait any longer.

Which is what they'd be doing (waiting) if I had not had the PCB house press full steam ahead in October because it took till now to find most of the issues and I still don't have a solution for the audio issue.  I've got some suggestions I can try but I don't know they'll fix the problem for certain.  And even if they do fix the current problem, what of all the noise that is generated when I power servos?   Fixing the LED drivers isn't going to fix that.  I haven't yet tested the servo noise issue with the ground loop isolator.  I suspect it will greatly reduce the noise, but not eliminate it completely, as has been the case with the LED drivers.  A combination of greatly eliminating and attempting to reduce it seems like the best course of action.  It's not like I have tons of space on the board to add big capacitors.

So I really had no choice in the matter. 

I agree with you that the noise is probably not caused by a ground loop.  Trying to alleviate the noise using techniques intended to fix ground loops is just going to be a waste of time.  There were some good suggestions a while back on trying to isolate the high current loops using capacitance and such.  Did you try that?  I know it's not what you want to hear based on board layout, but if you can, test the theory anyway.  If for no other reason than to prove it wrong and move on to something else.  Do whatever you have to do to get a large cap on the power rails near your LEDs and see what happens.

Oh, I believe them when they say it's the LED modules causing the noise, but modifying them at this point is not going to happen.  That is something that will have to wait for a redesign.  Right now, I am starting to ship the boards as is because with the ground loop isolator they work good enough for their intended purpose.  Adding more capacitance is something I will try when I have some time and before I get the next batch manufactured, assuming there is a next batch.

But assuming it is high current loops in the LED drivers... What would the isolation transformer on the RCA line be doing to fix that, and how might I replicate that without a big transformer?  (big relative to my tiny 2"x2" board I mean)  If it were simply that the board's ground was at a different potential than the amp, and I'm sure that's true as well, I would have expected the capacitors on the RCA cable to do something, but they didn't do a thing.

Oh I forgot to mention... I just tried disconnecting the ground to the Mighty and allowing the RCA to carry the ground, thus eliminating the ground loop, but I still get the noise.  So it seems it isn't the ground loop at all causing it.  Yet a transformer between the Mighty and the Amp in the RCA line fixes the noise issue.  It's gotta be the inductance or something.  Like I said before I also tried caps on both + and - RCA lines and that ought to break the ground loop as well but that didn't help with the noise either. 

Weird.  I could not get my board to power down just now with the power switch.  The power switch switches +5v to a logic level mosfet to turn the board on.  I traced the issue to the RCA cable.  It was plugged into the amp, which was off but connected to the same battery as the Mighty.

I can't for the life of me figure out how the mosfet could turn on to allow power to flow.  The pin that controls it is not attached to anything but a switch on the board which is off, and some pins for an external switch which is what I was using to switch it.  So the +5v had to have been coming from somewhere else.  But there is no connection to +5v from the RCA cable.  The + RCA line goes to the DAC output.

My schematic and layout are in this post btw:
http://arduino.cc/forum/index.php/topic,150336.msg1129683.html#msg1129683

[edit]

Oh wait, my mosfet doesn't switch 5V, it switches ground.  And the RCA cable carries ground from the amp.  DUH. 

Are you doing anything else in the code besides updating the servos?  Specifically anything which uses interrupts or disables them?  I've found that when the timing of the pulses that goes to the servos isn't perfect the servo will do that since it thinks it's slightly off from there it should be.

I tried something new with the circuit today because I have an amp to test with again.  I placed ceramic capacitors on both + and - RCA lines.  But this did nothing to help with the noise.

The thing is, I don't understand why it didn't help.  I've been told this is a way to break a ground loop.  And it certainly should block any DC current from flowing, just as the transformer in a ground loop isolator does.  So why didn't it help with the noise like the transformer did?

A transformer is really just a couple inductors, right?  So might the inductance be doing something to filter the noise?  I'm not sure how this could be, since the noise is smack dab in the middle of the audio range and filtering out those frequencies would filter out audio frequencies as well I'd imagine and affect the sound of the output.  But I have not noticed any change in the audio with the isolator in place.

I intend to add some more filtering to my LED modules when I do a second run of them, but I would really like to be able to emulate what this transformer is doing without using a huge transformer on my board when I redesign it, in case my changes to the LED modules are inadequate.