Katana - Roland GA-FC Foot controller communication

Started by CodeSmart, January 18, 2017, 08:42:11 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

sixeight

QuoteCapacitors to Identify:
C1145  -- small ; non-electrolytic (I'm going to go thru-hole)
C1154   -- small ; non-electrolytic
C1153   larger; Electrolytic

Transistor to Identify:
Q1100

C1153 and C1154 look like ordinary decoupling capacitors, usually they are 100n
C1145 is the tough one as it forms a filter with R1150 (56 ohms). Communication is at 62.5 kHz. Not sure what frequency this low pass filter is set at. I would try something small, like 10 nF.

Q1100 could be any PNP transistor, like BC 557.

Telegraph_Hill

#126
Thank you, sir!

I would be happy to purchase one of the MIDX boxes if it supports the GA-FC as an input device.  Again, my use case is different; it's not focused on the Katana, but more on adding more 'foot support' to Ableton Live.

I'll give it a try and post my results.

Also: I really studied the schematic yesterday and it looks like overkill to use the opto-isolators.  All the current is coming from the uC, so I don't see the risk of connecting directly to the GA-FC

The circuit, at a high level, looks to me to be: If the uC is transmitting, open the transistor gate for a path to the tip of the TRS plug. 
At the left hand side of the schematic, the paired resistors look to guide outbound current into the tip of the TRS to the GA-FC and away from the uC's input path.  (Assuming I'm correct that the current would rather flow onto the TRS tip than take the path past the 390 Ohm resistor (R1152).   Anyone want to school me on what a 'raw dog' circuit would look like (no isolators - try not to fry the uC).
Gumtown's post #71 (One Wire) looks interesting, but I think you'd have to cooperate on both sides of the wire.

Microprocessor heads: If I use one pin in INPUT MODE to receive data (normal case for the host side of the GA-FC) and then I change the pin's mode to OUTPUT to send the light status message... wouldn't that do the job with just one pin?  It seems like we have to account for collisions between TX/RX on the uC side in either case. I'm going to try that unless one of you says 'No! No! You'll surely let out the blue smoke if your try that!'

We know from numerous experiments (especially meo_udon's brave experiment with the Arduino) that a bare wire from a pin on the Arduino can talk to the Katana.  Without the isolators.

Has anyone gotten the bidirectional flow working really well from the GA-FC to a microprocessor?  Most of the attention seems to be on SIMULATING the GA-FC to the Katana. 

I'm all set to run my experiments this weekend.  Exciting, in a totally geeky I-have-no-life and I'll-spend-$200-getting-a-$100-part-working way.

My Siglent Technologies SDS1202X-E arrives this weekend, and I look forward to capturing some hot TX/RX action.  I've never used a modern 'scope -- my 30 year old Tek is still going strong, but not super well suited to signal analysis.

Cheers!


admin

#127
QuoteAgain, my use case is different; it's not focused on the Katana, but more on adding more 'foot support' to Ableton Live.

FWIW  -if your goal is controlling Ableton with a Foot controller  - there are already several available which focus on that  ( before you re-invent the wheel)


https://forum.ableton.com/viewtopic.php?f=1&t=141706


https://www.google.com/search?q=Ableton+with+a+Foot+controller&rlz=1C1GCEU_enUS821US821&source=lnms&tbm=isch&sa=X&ved=0ahUKEwiejeWkuvjfAhXLGjQIHVxUA1IQ_AUIECgD&biw=865&bih=639


Looptimus USB midi foot controller/pedal for Ableton Live--great for guitarists
https://reverb.com/item/917200-looptimus-usb-midi-foot-controller-pedal-for-ableton-live-great-for-guitarists




Keith McMillen Instruments SoftStep 2 USB Midi Foot Controller
https://reverb.com/item/14426311-keith-mcmillen-instruments-softstep-2-usb-midi-foot-controller

Telegraph_Hill

#128
Yes, I totally agree that there are good options out there.  Thank you for
listing those...  Those are really good suggestions.  I'd love to get the
12-step 2, but it's a little pricey.  I'd rather recycle the controller I have
(and solve this puzzle) than buy the 12-step.  But with a little G.A.S.
patience I'll probably pick one up, eventually.  (Always Buy More Gear.)

I'm sorry that Looptimus went out of business.

I am a backer of Vince Cimo's Datalooper pedal:
https://www.indiegogo.com/projects/datalooper-the-loop-pedal-built-for-ableton-live/x/19427475#/
I think he's really on to something.  But ugh!  Having to mess around with all that Ableton Midi Remote Scripting!

Luckily, we are in a golden age of midi controllers.  Have you guys checked out nativeKontrol?
https://www.nativekontrol.com/
So many control surfaces! 

But I digress.  This forum isn't about Ableton.  But I still want to use the GA-FC with it.  And so I press on!

Dear reader: Do not take my course!  Surely it is madness!  The above devices
are better conceived and executed.

* * * Still with me? * * *

The GA-FC presents an interesting engineering challenge to me.  It's so simple
conceptually, but they have made it so baroque because of the requirement to limit
the implementation of the protocol on a 3-wire TRS connection for what should obviously
be a 4-wire solution:

1) power,
2) TX,
3) RX, and
4) ground. 

(USB, anyone?)

No 1/4" TRRS cables?  That would have made it easier!  The closest I found is a variant
of the truly venerable 1/4" plug, but sadly with a different diameter. 

http://connectors.nexus.com/image?prodid=3001001&itemid=1001&imgname=tp120.jpg

But hey!  TRS cables are everywhere!  And this protocol probably pre-dates USB by... a decade?
Any patent hounds here?  I'd love to see Roland/Boss's patent for this.

Am I right, or is there something perverse about this little controller?  Isn't that what
draws us to this forum and thread?

* * * A BIT LATER... I WAKE UP FROM A NAP WITH AN ALGORITHMIC  SOLUTION!  * * *

Today I had an epiphany about the **half-duplex** nature of the
communication scheme.  I 'got' how the communication works.  The GA-FC
controls the whole show.  Interestingly, the Katana is the 'slave' in this
system.

The logic is centered on the pacing of messages across the wire.  The key
design point is that the GF-CC controls the timing and content of what it
sends up.  The Katana has a much narrower set of options (only one!): 

Reply to every message from the GA-FC with a single status message.

I think: the GA-FC has a duty cycle, looping forever, in the following priorities:
Each time it is the GA-FC's time to send a message, it can only send ONE
of the following, in this order:

    1) REALTIME / Expression Pedal
    2) Button Press
    3) Keep-alive / state update

The key is the GA-FC controls the pacing.  And so, for each of its three message
types, it sends the message (one duty cycle), and listens for 2.5 or 3 cycles.
It just has to be long enough for the packet to complete the round trip.  Call
it 3 duty cycles.  It expects (hopes for?) a reply for every message.   But if
there is no reply, it simply repeats the process.  Never any collisions.

Note that the GA-FC probably has logic to intersperse button (type 2) and
keep-alive (type 3) messages when the user is is in the middle of a long
shred-fest/expression-pedal-heavy solo.

Whenever the Katana receives a MIDI message from the GA-FC it 'flips the pin'
on the single TX/RX line transmits its response.  After sending this message the
Katana is silent until it receives a message from the GA-FC. 

Thus there is a 'window' of 2 duty cycles on the GA-FC side to wait-for/listen for
the status messages from the Katana, which is sent back EVERY TIME the GA-FC
sends any one of it's 3 types of messages..  The Katana NEVER sends to the GA-FC
unless it's in response to a message from the GA-FC.

I think there is NO collision on the wire.  The fact that the GA-FC is the
driver in the communication makes it possible.  It doesn't send ANYTHING
except according to the priorities listed above -- there is no flood of
Expression pedal messages, no need to back off and get back in sync.

My problem is I was thinking of this like TCP/IP and Ethernet, which deals with
collisions all the time.  This is, in its own way, far simpler.

If it takes 1 'cycle' to send a message across the 'bus' wire, and one to send
the reply back, then the third cycle is reserved for 'slack' in the
communications to handle the tiny asynchronous nature of the protocol.

Also this means that the GA-FC will never send expression pedal info faster
than 3x (maybe 2.5x) of a cycle.  It can never get backed up.

The messages are tiny; a dozen bytes per packet, or less.  And at 64,500 baud,
that moves pretty fast.  On the order of < 1 ms per message.  So, potentially
the Katana can get a stream of expression pedal messages at one per 3
milliseconds.  That's fast enough for me!

I am going to code this up and see if it works.  I'll post a github link when
it's available.  I feel a sense of connection with the engineers who came up
with this scheme, and for this forum, which has helped shed light on this
puzzle.

I'm going to try to capture the packets and visualize the protocol.  Would be cool
if this is actually the way Roland/BOSS has implemented it.  The key indicator would
be a lack of collisions.

I'm sure @admin and @sixeight are face-palming right now because of how long
it took me to pick up on this.  (See posts 54 and 55 in this thread) Thanks for
being patient with me, guys.  Sorry for the TL;dr

Thanks, everyone! 

gumtown

Great job, that totally aligns with my assumptions (er..guess) from my previous post.

Free "GR-55 FloorBoard" editor software from https://sourceforge.net/projects/grfloorboard/

sixeight

About the GAFC being in the lead;: most of the time the GAFC is controlling the Katana, but when you change channels on the Katana, the GAFC will show the new channel. So the GAFC is listening to the Katana as well.

A simultaneous channel change on both the Katana and the GAFC could cause a collision in theory, but when does that happen in real life....

vtgearhead

Quote from: Telegraph_Hill on January 18, 2019, 02:07:56 PM
Also: I really studied the schematic yesterday and it looks like overkill to use the opto-isolators.  All the current is coming from the uC, so I don't see the risk of connecting directly to the GA-FC

Three words:  Static discharge protection

Those who couple ESD sensitive devices directly to free-running lengths of cable eventually come to regret it.  Famous example can be found in a pre-ethernet networking scheme called Omninet.  The first run of interface boards connected driver and receiver devices directly to twisted-pair building wiring.  I'm guessing about 98% of them were zapped in the field.  The company quickly reworked umpteen thousand cards by slapping on a daughter board containing a pair of opto-isolators.

vtgearhead

Quote from: sixeight on January 19, 2019, 01:16:47 AM
About the GAFC being in the lead;: most of the time the GAFC is controlling the Katana, but when you change channels on the Katana, the GAFC will show the new channel. So the GAFC is listening to the Katana as well.

A simultaneous channel change on both the Katana and the GAFC could cause a collision in theory, but when does that happen in real life....

Always.  Seriously, having developed and maintained highly parallelized engineering software for much of my career, I state with assurance that any possible race condition will eventually occur - and always at the most inconvenient time.

sixeight

Quote from: vtgearhead on January 19, 2019, 06:26:31 AM
Always.  Seriously, having developed and maintained highly parallelized engineering software for much of my career, I state with assurance that any possible race condition will eventually occur - and always at the most inconvenient time

The result of the action above would be that the Katana will be on the channel that was selected on the unit and the message from and to the GAFC would be lost, so it might show the wrong patch.

Both ends can check if the message that was sent has been lost in a collision, as all messages that are sent are received by the sending side as well. They share the same communication line. As long as both ends have a different timeout, messages can be sent again and all is well.

Telegraph_Hill

Hi guys, my adventure to provide a non-Katana 'host' for the GA-FC continues.  Here's some data I thought you all might like...

A screen shot of MIDI from the Saleae Logic 8 analyzer.  This is a bargain compared to a multi function oscilloscope.  Check for the 'maker' discount on their site.  Good stuff...

Also the raw decoded data from a 5 second capture.  It does appear from the decoded data that collisions are in fact happening on the line.

What's interesting (to me at least) is that the responses from the Katana to the GA-FC are in 'proper order' -- that means, I believe, that the Katana is replying 'in reverse'.  I will have to validate that theory.

My 6N138 optical isolators arrived a few days ago.  I'm going to continue to breadboard the circuit from this thread.

Thanks again, everyone, for paving the way.  This is a great learning exercise for me.  And a puzzle.


Telegraph_Hill

Hello again. 

NOTE: My conclusion that there were collisions on the line was incorrect in my previous posting.  I was confused.  No Collusion!

I ran a few scenarios and captured the data from the logic analyzer.  File attached.  The format is: length of the packet in bytes, then the sysex messages.

e.g.:
9: [F0, 00, 00, 37, 7F, 00, 00, 4A, F7]
6: [F0, 00, 00, 04, 7C, F7]
7: [F0, 00, 00, 41, 7F, 40, F7]

I found that CodeSmart's Communication Specification is highly accurate, with the following exception: Amplifier Response Messages are sent by the Katana in response to:
Time Status Messages
Foot Switch Messages

And they are not sent in response to Expression Pedal messages.

I observed no collisions or 'backing off' in the captures, despite some energetic testing with button mashing and expression pedal air-guitar action.  (Thanks go out to my 10 year old daughter for her help!)

So, a really 'raw' implementation of this could probably be made with one pin on the microprocessor changing from INPUT to OUTPUT mode when it receives TIMED or FOOT SWITCH messages.  It should listen the rest of the time.

I'm implementing my circuit with optical isolators to protect the microprocessor's pins from electrostatic discharge.  I'll send another update when I have my GAFC->MIDI adapter working.

This has been a fun introduction to logic analysis and circuit design.  Thanks again everyone!

admin

FWIW -

If you can solder you can build a GAFC functional equivalent thats already working with code here


(Teensy) USB MIDI foot controller for Katana amps
https://www.vguitarforums.com/smf/index.php?topic=25185.0

Telegraph_Hill

well, that'll save me some time!  This is a replacement for the GA-FC, right?  I'm noodling around with creating an adapter from the GA-FC to ableton live.  Yes yes, a fool's errand, but I'm going for it.

SteveO

Quote from: Telegraph_Hill on February 19, 2019, 12:30:47 PM
well, that'll save me some time!  This is a replacement for the GA-FC, right?  I'm noodling around with creating an adapter from the GA-FC to ableton live.  Yes yes, a fool's errand, but I'm going for it.

There's a couple of caveats; the expression pedal code and wiring isn't done yet and only two of us have made this controller. I'm not sure if the expression pedal can be programmed to work the same way it does on GA-FC, i.e. volume normally and an effect other times. Right now I have some rudimentary code that allows an expression pedal to act like switch #2 and control 1 of the pedal wah effects only.  So, it's still very much experimental.

CodeSmart

I can just confirm that the information (drawings and protocol) provided earlier is correct. I can now use a GA-FC connected to a PIC Microcontroller and do whatever I want with it.
- Setting individual LEDs on/off
- Capture FS and Expression Pedals change events.
- Capture the timed messages (abt. 3 per second)

Regarding the schematic I skipped the transistor as the controller can drive optocoupler directly. TX polarity had to be inverted (PIC controller UART register setting)
But I got more gear than I need...and I like it!

CodeSmart

Quote from: CodeSmart on April 01, 2019, 12:33:29 PM
I can just confirm that the information (drawings and protocol) provided earlier is correct. I can now use a GA-FC connected to a PIC Microcontroller and do whatever I want with it.
- Setting individual LEDs on/off
- Capture FS and Expression Pedals change events.
- Capture the timed messages (abt. 3 per second)

Regarding the schematic I skipped the transistor as the controller can drive optocoupler directly. TX polarity had to be inverted (PIC controller UART register setting)




The communication as seen on an oscilloscope shows the red burst sent by the microcontroller, which is a response to the first yellow burst (a timed message sent by the GA-FC). The red burst will program the states of the LED's.

Because the conversation is carried on one wire (half-duplex), the transmitter will also see what he just sent, hence the second yellow burst.

Besides timed messages sent 3 per second, there are immediate messages sent when a expression pedal is rocked or a foot switch is changing state.

Also in the case of foot switch messages, the microcontroller may want to immediately change the LED state.



But I got more gear than I need...and I like it!

vit3k

Does anyone know if katana takes simple program change messages on ga-fc port? Or only those sysex with buttons states described by CodeSmart?

Regards

vtgearhead

Quote from: vit3k on April 02, 2019, 01:08:11 AM
Does anyone know if katana takes simple program change messages on ga-fc port? Or only those sysex with buttons states described by CodeSmart?

Regards

Of course it takes program change messages.  How else would the channel select footswitches work?

vit3k

As far as I understand, from the spec that CodeSmart created, GA-FC is a dump footswitch that sends the state of the switches, not commands to the amp. For example it says: switch 1 is pressed. Then Amp decides what to do with this (based on state - switch channels, change bank, turn on/off effects).

So my question is still valid in my opinion.

sixeight

#144
Quote from: vit3k on April 02, 2019, 01:08:11 AM
Does anyone know if katana takes simple program change messages on ga-fc port? Or only those sysex with buttons states described by CodeSmart?

Regards

As I have stated before. Because the GAFC connector combines both in and out lines on one connection, the connection is half -duplex. So the designers must have limited communications to avoid collisions.

The oscilloscope shots shown so far only show the custom sysex commands and no other data.
Sending PC, CC messages or the sysex data the editor uses over the GAFC connector would serve no purpose and only cripple the communication between the Katana and the foot pedal.

vit3k

For me the purpose would be to use this as a way to switch to any of the 8 channels immediately using my diy controller without using USB.

sixeight

#146
Quote from: vit3k on April 03, 2019, 04:07:14 AM
For me the purpose would be to use this as a way to switch to any of the 8 channels immediately using my diy controller without using USB.

That should be possible. The diy controller could simulate pressing several buttons after one another.

Or you could use a Teensy 3.6 with USB and have more options. I have the host port working with the Katana.

vit3k

I think that switching banks requires holding panel switch for a while so it will not work immediately. I would like to leave USB for editing with android phone but I suppose it's the only way to send program changes.

Great to hear that you make the usb host on teensy 3.6 to work with katana.

sixeight

Quote from: vit3k on April 03, 2019, 09:56:51 AM
I think that switching banks requires holding panel switch for a while so it will not work immediately. I would like to leave USB for editing with android phone but I suppose it's the only way to send program changes.

I read somewhere that you can switch banks quickly by connecting an external footswitch to one of the expression pedal inputs of the GAFC. Maybe CodeSmart can confirm and catch the correct sysex command for this.. 

CodeSmart

Quote from: sixeight on April 04, 2019, 06:48:55 AM
I read somewhere that you can switch banks quickly by connecting an external footswitch to one of the expression pedal inputs of the GAFC. Maybe CodeSmart can confirm and catch the correct sysex command for this..

I don't believe that is true. I think I tried connect a FS to the expr. inputs when I wrote the comm paper.
But I got more gear than I need...and I like it!