toggle quoted messageShow quoted text
Please send me a copy as well.
On Oct 25, 2013, at 8:43 PM, whippinpost91850@...
In a message dated 10/25/2013 8:38:44 P.M. Eastern Daylight Time,
I also appreciate if someone forward to me the schematics:
Enviado via iPhone
My fcb1010 has been flaky and I've actually had it boxed up and stored
for a long time. I don't know when I'll get around to it, but the
schematic would be a help looking for a fix. If someone would share,
please send it to "palmquistdavid" at yahoo .
That certainly explains alot. Thanks
To: fcb1010 <fcb1010@...
Thu, Oct 24, 2013 9:57 pm
Subject: [fcb1010] RE: Schematic
Okay, here's what I've found on the FCB's expression
What they did right - during calibration, they keep a running
average on the last 8 readings. Also, they do the calibration scaling at the
full 8-bit resolution, prior to converting to the 7-bit MIDI volume CC
What's not so great - they don't appear to be doing any
averaging during the actual operation of the expression pedals. Also, while
they followed the datasheet on the TLC0832, they are actually clocking the
A/D more than they need to. One can put out 20-something clocks and wind up
with the LSB-first data. However, the A/D puts out MSB-first data prior to
that (SAME data), which the FCB is discarding. Since CS going high will
reset the state machine within the converter, one can save the MSB-first
data and then stop clocking the A/D. Essentially, they are taking twice as
long to read the converter as required.
I did a coarse check on the pedal
travel vs. A/D reading... The transfer function is abysmal. Best-line fit is
almost linear, with some bumps in it and flat spots at the end of travel.
Some of that is due to the grayscale strip (apparently) being mostly linear,
but some of it is likely due to the simplistic design of the phototransistor
circuit. They are using a phototransistor with a collector load resistor,
which means that Vce varies with collector current, so the beta of the
transistor changes, and the CTR of the overall circuit varies as well. I
would've used a current mirror in the emitter of the phototransistor to
maintain a constant Vce...
Also, I need to analyze the code a bit
more to be certain, but it looks like they are artificially "cramping" the
range of the pedal at both extremes.
The almost linear transfer
function of the pedal is the reason that it doesn't "feel" right. I plan to
change the operation of the expression pedal when not in calibration mode.
I'll likely build a lookup table to provide an audio "taper". I will likely
also implement some averaging. I'll do that averaging AFTER the lookup
table, in order to gain some resolution and help prevent possible
"zippering". I also plan to change the "update" threshold to be below
5 counts, since I plan to average. I'd also like to slightly extend the time
that the pedal value is on the display, it's a bit short right
We'll see how this works out.
Thanks to the kind soul who sent me a schematic! I likely could've
sketched up something and figured out the code on my own, but the schematic
is helpful... I still have LOTS to do analyzing the code and making mods,
but thought I'd post some initial stuff.
did some things well, other things not so well. I do give them credit for
providing a good foot controller at a good price. Looks like the software
was likely done in C, because looking at the disassembly there are some
pieces of code that are obviously not optimized. Nothing wrong with that,
but as one who has been in the embedded systems business for over 30 years,
I have a good feel for compiled code. The firmware is at least better than
the Digitech Control 8, which was also likely done in C, but by someone not
very experienced... Their switch debounce was HORRIBLE with a LOT of
patch-switching latency and they didn't even use interrupts for the serial
comms (they did a tight loop on JNB TI,$ to send data!), which wasted
time that could've served to help debounce in a timely manner or other
on the FCB expression pedals in the next message.
Yeah, I knew that it took a 5-count change to get the FCB to send a new
pedal value. That's not a major problem. The comment about oscillation of
values tends to confirm my suspicion that they are not doing any averaging
of the A/D readings, and the lack of pedal friction doesn't help
'0832 is a dual serial A/D converter, and the port 1 pins are used for the
pedal setup is similar to the Digitech Control 8, which also uses a
grayscale strip. However, the pedal on the C8 works well, and has a good
audio "feel" to it, and doesn't have a big "dead zone" on the toe end. The
grayscale strip on the C8 is well-done, and they ARE averaging A/D readings.
I changed my C8 firmware because of the poor debouncing and the latency in
patch-switching, and tweaked the pedal firmware slightly as well.
understand that the schematic is not "public domain", so would appreciate if
someone could email me a copy at kr.baker@...
As it was explained to
me, the schematic isn’t public domain so the few guys who do have it don’t
share it very often.
The last travel portion of the pedal travel
doesn’t do anything but is directly related to the length of the grey scale
Behringer also doesn’t send every value between min and max
when you rock the pedal any way. If you watch the output they count by
It also takes a “move” of 5 ticks to even get the firmware to
recognize the pedal is being moved. That’s their debounce routine, trying to
make it more responsive produces varied results because the pedals lack any
real friction/feedback. They can oscillate with values in some positions all
on their own. Longer travel pretty much limits you to changing the
Thus as a smooth volume swell pedal, it’s better
suited as a foot rest.
The LED/transistor sensors feed a TLC0832 IC
for the A/D on the two channels. That in turn feeds P1.0, P1.1, P1.2 on the
80C32. Nothing magical about that setup.
10/21/13 5:27 PM, "kr.baker@..." <kr.baker@...>
I'm in need of a schematic, which seems to
have disappeared from this group.
At practice recently, I noticed
that the expression pedals were a bit "goofy". I have a GSP1101 setup to
trigger Wah via "toe switch", which always toggled way too early on my
"Expression B" pedal. On when it shouldn't be, etc.... I did a
calibration, and noticed that Behringer conveniently provided a hex
display of the A/D convert value. Mine went from 08 to EE, so I
calibrated. No help with wah. However, I also noticed that the last HALF
INCH of the pedal around toe down changes value VERY little. Add that to
the (apparently) linear transfer function, and the pedal operation is
abysmal. Not very friendly for use as volume, and killing me on the wah. I
fixed the way by adding rubber on the pedal AND the board, so that I could
push it for on/off. Still, the transfer function is not
Since I'm an embedded systems designer (analog/digital
hardware and software design), I want to look into this more fully. I
"suspect" that the software guy took a rather straightforward approach to
the pedal reading/calibration, and since the A/D value appears to be 8
bits and the MIDI value can only be 7 bits, that they are actually losing
resolution in calculations. Also, don't know yet whether they do any
averaging, which can actually (potentially) gain a couple of bits of
resolution. I have no idea whether the optocoupler is optimized, but I
know that many people have replaced the plastic strip that has the optical
gradations because the transfer function of the pedal is more "linear"
taper than "audio" taper. Keeping resolution on the A/D readings MAY
potentially help solve that, because the transfer function may be able to
be solved via software, and extra resolution would make that work much
better. I'll know more if/when I can get a schematic and look over the
IF (and that's a big IF!) I think I can make some improvement,
I'll test it. If it works out, I'll be happy to submit the code to the Uno
people so that they can incorporate it. It would be nice if a software fix
could improve things, instead of the tedious (and risky) chore of
replacing the optical-graded plastic.