Re: Schematic


Bruce Collins
 

Please send me a copy as well.


On Oct 25, 2013, at 8:43 PM, whippinpost91850@... wrote:

 

me to ,please     whippinpost91850@...
 
In a message dated 10/25/2013 8:38:44 P.M. Eastern Daylight Time, mrtubeamps@... writes:
 

I also appreciate if someone forward to me the schematics:

Regards,
Daniel 

Enviado via iPhone

Em 25/10/2013, às 14:57, <palmquistdavid@...> escreveu:

 

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 . 



---In fcb1010@..., <fcb1010@...> wrote:

That certainly explains alot. Thanks
-----Original Message-----
From: kr.baker
To: fcb1010 <fcb1010@...>
Sent: Thu, Oct 24, 2013 9:57 pm
Subject: [fcb1010] RE: Schematic

 
Okay, here's what I've found on the FCB's expression pedals:

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 value.

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 now.

We'll see how this works out.
 


---In fcb1010@..., wrote:

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.

Behringer 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 tasks.

Details on the FCB expression pedals in the next message.


---In fcb1010@..., <fcb1010@...> wrote:

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 that.

The '0832 is a dual serial A/D converter, and the port 1 pins are used for the serial interface.

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.

I understand that the schematic is not "public domain", so would appreciate if someone could email me a copy at kr.baker@...


---In fcb1010@..., wrote:

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 strip.

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 twos.

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 transparent strip.

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.

Mel
---

On 10/21/13 5:27 PM, "kr.baker@..." <kr.baker@...> wrote:



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 right.

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 code.
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.




Reply via web post Reply to sender Reply to group Start a New Topic Messages in this topic (8)

Join main@fcb1010.groups.io to automatically receive all group messages.