Creative Communities of the World Forums

The peer to peer support community for media production professionals.

Activity Forums AJA Video Systems Kona3 RS422 interrupts

  • Kona3 RS422 interrupts

    Posted by Joseph Owens on December 14, 2010 at 6:15 pm

    I have a really consistent interruption concerning RS422 control of external drives from the Kona3.
    99 times out of 100, and this is a measured value, not an estimate, Log and Capture and Edit to Tape come up “No communication”. Nothing solves the situation, and I mean nothing — not re-installs, not jiggling the cables (and they only go into the sockets one way), not upgrades, not restarting FCP, not restarting the modules, nada. The only thing that restores machine control is a total system shutdown and reboot.

    Not what I call professional performance.

    Anyone with insight or a rewrite of the code?

    jPo

    You mean “Old Ben”? Ben Kenobi?

    Joseph Owens replied 15 years, 4 months ago 7 Members · 17 Replies
  • 17 Replies
  • Jeremy Garchow

    December 14, 2010 at 7:06 pm

    What device?

    Are you sure you have the proper deck control setting selected?

  • Tom Bucknall

    December 14, 2010 at 8:50 pm

    I don’t know if this will help but it might be worth a shot.

    https://support.apple.com/kb/HT1942

  • Chad Brewer

    December 15, 2010 at 3:36 am

    Joseph,
    I’ve dealt with some similar RS422 issues with one of our Kona3 cards on an older MacPro. What vintage is your MacPro, what version of Kona drivers are you running, and like Jeremy said, what decks (I assume you meant decks when you said external drives) are you looking to control?
    If your issue is similar to one of our edit stations, I MAY have a simple solution to the problem from my what I’ve encountered, but I can’t say without knowing what you have at hand.

    Chad Brewer
    Senior Tape Operator/Engineer
    TeleVersions

  • Bob Zelin

    December 15, 2010 at 11:37 pm

    You write –
    I have a really consistent interruption concerning RS422 control of external drives from the Kona3.

    You mean RS422 control of external VTR’s, correct ?
    You have not mentioned what VTR you are trying to control ! Is it a Sony Digi Beta, or a Sony UVW-1400 ? Is it a Sony HVR-15M2U with a Convergent Design Firewire to RS 422 adaptor. Is it a Panasonic
    AJ-SD455 DVCPro VTR ? Every one of these can cause different issues !

    OK, so lets make believe that you have a Sony UVW-1800 VTR, and you get “no communication”. It could be the following (this has nothing to do with “bad code”) –

    1) your AJA K3 box (do you own one ? ) is defective, or your cables between your K3 box and the Kona 3 card are defective.

    2) if you do NOT own a K3 box, the Kona 3 breakout cable that came with the board is defective

    3) the Kona 3 itself is defective

    4) have you trashed both your FCP preferences, AND your AJA Kona 3 preferences ?

    https://www.bobzelin.com/how-to-delete-aja-kona-preferences

    NOW, MOST IMPORTANT – STOP using Final Cut Pro for these tests. Download the free AJA VTR XChange from the AJA website, and use AJA VTR XChange to control your VTR. If VTR XChange works, but FCP gives you “no communications”, then it’s FCP (probably the preferences need to be trashed, or your system drive is corrupt). If AJA VTR XChange DOES NOT work, then try what I suggested above.

    Bob Zelin

  • Joseph Owens

    December 20, 2010 at 7:58 pm

    Thanks for the insights. I’ve been away on remote for a few days.

    Decks in the system: Sony: SRW5500, DVWA500, PVW2800, UVW1800 and DSR45.

    They all exhibit the same behaviour. I am running FCP7.0.2. Kona control panel8.0 nondesktop version (FCP crashes almost incessantly with the desktop version), Kona3, firmware updated on a MacPro 3,1 2.8GHz Dual-Quad Xeon running Snow Leopard 10.6.4.

    All direct RS-422 via a K3-breakout box (which AJA seems to have some serious build problems with)… I don’t have to jiggle any wires or re-seat any connectors. It is always a complete system shutdown that fixes the loss of communication. VTRXchange: same behaviour, but even if it worked, I require the Edit-to-Tape module (worst edit controller in the space-time continuum) for its Closed Caption insertion.

    As I’m typing out all this stuff, I’m realizing what a ridiculous house of cards built on sand this really is.

    jPo

    You mean “Old Ben”? Ben Kenobi?

  • Jeremy Garchow

    December 20, 2010 at 9:20 pm

    [Joseph Owens] “All direct RS-422 via a K3-breakout box (which AJA seems to have some serious build problems with)… I don’t have to jiggle any wires or re-seat any connectors. It is always a complete system shutdown that fixes the loss of communication. “

    At what point to do you hook all these decks up to the Kona? When the ETT window is open?

  • Joseph Owens

    December 20, 2010 at 9:45 pm

    Usually the SRW5500 is my default machine and its left connected almost permanently. I try not to “hot” plug any control interfaces, and at first, I thought this was the issue. But not. Having the machine warm before starting FCP, coldstart, hot swap, restart FCP, makes no difference. It has to be a complete hardware shutdown and restart, and sometimes the machine will disappear after a successful mastering pass and the next tape in will require a shut down before I can address the VTR again, which means setting up every last detail all over again.

    I still can’t believe that its the “Capture/Input” setting that determines the output of the Kona when you use Edit to Tape.

    jPo

    You mean “Old Ben”? Ben Kenobi?

  • Jeremy Garchow

    December 20, 2010 at 9:59 pm

    [Joseph Owens] “I still can’t believe that its the “Capture/Input” setting that determines the output of the Kona when you use Edit to Tape.”

    The reason is, when you go to Edit To Tape, the Kona is actually looking at the video input from the deck (so in essence it is going to capture mode). At this point, the Kona also references incoming video as it does for every capture so genlock doesn’t help here.

    This would allow you to cue the material on the tape itself. If the Kona was just in output mode, there’s no way to see what’s coming from the tape deck in the ETT window if you didn’t have a monitor (I know, silly proposition, but it’s true). As soon as you hit Edit to tape, FCP Switched the Kona to output mode and then genlock comes in to play.

    For SR decks, it’s best if the Kona matches the settings of the SR deck before opening that feedback loop. The SR decks can freak out if they see something like the mess that FCP can put out when opening ETT.

    If none of that works or makes sense, I’d call AJA and get a new card. That kind of trouble seems like a hardware problem.

    Jeremy

  • Joseph Owens

    December 21, 2010 at 5:10 pm

    No, this has more of the feel of a Snow Leopard problem, since that is when this all started really coming apart consistently.

    Also, there is no SDI-in loop from the SR deck output, so the Kona isn’t seeing anything. Its running free/slaved to FCP/ETT/Control Panel. I do not use the internal Kona monitoring as it would essentially be a feed-back loop. I monitor everything externally through actual scopes and actual monitors. If any of the preview lockup stuff were true, the system restart would also fail, because nothing has been changed, connected, disconnected, re-routed or anything.

    I am not a basement enthusiast, I’ve been delivering network tapes for nearly thirty years. The last five years have been almost pure and undiluted hell with this Apple garbage, and over the past six months has descended into being utterly unacceptable. Put “Fisher-Price” on the package, and I’d believe it.

    jPo

    You mean “Old Ben”? Ben Kenobi?

  • Jeremy Garchow

    December 21, 2010 at 5:16 pm

    You should try feeding your kona stable black/video when opening ETT.

    If your deck is not in EE, then you should be able to
    close the loop.

    Have you contacted AJA and tried a new card?

Page 1 of 2

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy