Anyone familiar with Raven's MX4 Blade voter?

[jmfirefighter20]

Looking to see if anyone on here is familiar with Raven Communication's MX4 voting blade/system.

Been working on some issues with our local radio service shop and all of us are stumped, and Raven's tech support has been less than helpful.

Let me know....we'd appreciate any input. I'll go into more detail if someone replies.

[Bill_G]

I've only worked with Raven's audio bridge, but their MX4 series modules looks kind of interesting. Tell us more about what's it's doing / going wrong. Maybe we can help you brainstorm it.

[jmfirefighter20]

Well our issue stems from trying to get our two voters working the same, one is primary and the other is a "hot standby" should something happen to the other one.

Our primary unit has been working for a few years and has no issues, but the service company seems to think it has corrupted software due to some old VoIP coding left on it. I do not know if we were ever a VoIP system here, so I can't really confirm or deny that.

The secondary voter is supposedly programmed "exactly" like the primary, however when we plug it in to use it we get a horrible echo that the dispatchers can hear. At times the echo is throughout a transmission/receive, sometimes just in recieve, sometimes just in transmit, and sometimes just in the tail end of a transmission.

I have verified the connections in the CEB room and traced each wire from each site back through the system. I cannot find a location where any wires are misplaced. I have listened to our logging recorder which has also caught the echo at times, but it seems to be centered around our OP positions. I can capture the echo in the tapes when I listen to the individual OP's "selected audio" channel. One of our logging recorder inputs connects post-voter at the CEB punchblock without the consoles and only had an echo once.

This is all using the same wiring as the primary voter. It only occurs when the secondary voter is connected. If I replace it with the primary, it's fine.

It's a very ANNOYING issue that myself and our service company cannot seem to get our heads wrapped around, even with the tech support at Raven.

Any input you can offer is appreciated. I'll try to answer any questions you may have.

Thanks

[Bill_G]

Has the secondary unit been sent back to the OEM for service?

[jmfirefighter20]

Yes, it has. Spent a week there being looked at and upgraded. They found nothing wrong with it and added the newest version of firmware.

I double checked that there is no "outside" audio getting into the console by unplugging the BIM audio input line from our patch panel. Console was completely deaf afterwards, so it minimized that possibility.

I finally got a copy of the software from Raven to play with this thing. A few interesting items of note:

1.) We are running a VOX vote system.
2.) Our "free vote" time is 1500 ms, which according to the company, and to me, is incredibly too high.
3.) Often, the secondary voter will actually appear to lock onto two sites at the same time. If it's actually doing this, I don't know. But our vote indicator lights show this.

[jmfirefighter20]

Well now that I've been able to plug into the voters, I found that they were in fact NOT programmed the same. I have now got their programming the same, and am now testing. So far so good, but we really haven't used it yet. I'll let you know the outcome.

Another interesting note, however, is that the Raven is configured via USB. When a PC is plugged in with the software, the PC actually becomes the voter as it's software is loaded onto the PC. You have to physically write the software to the voter for it to take effect.

[Bill_G]

Is this voter used as a repeater controller too, or is it used to tie multiple rcvrs back to the console?

If it is a repeater controller, is the echo heard in the repeat audio, or just at the console?

2 wire or 4 wire circuits to the stations and console, and are they leased line telco, microwave hops to the sites, or in house wiring to the rooftop?

Echo suppression on long telco lines is an old problem generally overcome by balanced circuits, and hybrid terminations with some attenuation thrown in on each side. My guess is the supposedly balanced wiring is no longer balanced, additional gain (or less attenuation) was applied to overcome the loss on one leg, and the secondary voter doesn't present a true 600 ohm termination to the line to suppress the echo. This can be verified with a TMS set. At the very least put a 1k resistor across the terminals where the wire pairs land on the Raven to see if that kills the echo.

[jmfirefighter20]

Nope, this unit is strictly receive only tying multiple sites into one output.

Everything that ties into this voting system is via microwave hops.

All are 4 wire circuits, the TX pair ties directly to the CEB and the RX pair is diverted to the Voting shelf.

If the echo comes back I will try the resistor trick and see what happens.

Thanks.

[jmfirefighter20]

Just as a follow up, I actually found the cause of the echo. In the voter's port settings for the console port, there was a 250 msec delay in the audio. I did a little testing today where when I put the delay back in, the echo returned. As soon as I took the delay back out, the echo stopped.

Thanks for lending an ear and giving me some troubleshooting options!

[Bill_G]

If you add the delay to the primary Blade, does it cause an echo as well?

[jmfirefighter20]

I have been warned to not play with the primary voter until the testing on the secondary one is done. We're going to let it run for a few weeks before we start working on the primary one. Apparently, according to the company, the primary voter has "corrupted firmware" and that playing with it could brick the unit. I don't want to do that, or even try to play with it, until I am sure this new one is working.

I will get back to you in a few weeks and let you know the results.

[Bill_G]

I'll be interested for sure. Turning off the delay killing the echo suggests there is a dual path within the Blade - one time adjustable, and one not.

[n3lee]

I wonder if the console port is set up full duplex instead of half duplex; causing the echo to be heard by the console... M4X is a good unit but the softwares a bit screwy.

[jimbo5169]

I have quite a bit of experience with their voting system. What would you like to know?

[jimbo5169]

My observation: The Raven product is a whole lot of technology, mostly software based, packed in a very compact package. The ports can be configured as inputs and ouputs with many methods of control. It will produce keying tones or provide E&M control. The receiver inputs can be either status tone controlled, 2175 or 1950 or COR/TOR + or - polarity. You can also configure one or more ports as a console input that will provide priority audio over any receiver input. This all works pretty well, however there are a few things it won't do. One being you can't provide a PTT closure into the console input and have the Raven produce keying tone out to key the transmitter. Your console must provide the keying tones and the Raven passes them to the transmitter port. For a while we had a problem with the Raven making keying tones for the receiver repeat and when the console came online, the keying tones from the console would phase cancel and the transmitter would drop out. Raven corrected this by cancelling the Raven keying tone when the console port detected input activity. There are more of these stories but I think this paints the basic picture.

My Opinion: The Raven product has been designed by some really creative engineers. In a lab environment it works great. However in the real world it comes up very short. First of all they expect that all of the receiver audio will have the same characteristics. They expect the media between the receiver and voter to have constant audio response and the line loss is constant without any variations. It isn't designed to work with leased lines as a means to connect the receivers to the voter. In short, they designed their product based upon all parameters being constant with the only variable being receiver generated noise do to weak signal conditions.

I have spent hundreds of hours working with this system and have one of their voters in service in a local police department. It has been reliable, but took months to get it working. It quite often mis-votes and votes a noisy receiver. Personally, I will not install another one unless it is a completely new radio system where I have complete control of all parameters surrounding the voted system.

If you have any further questions, please feel free to ask.

[jimbo5169]

The Raven voter has default delay in each of the ports regardless of their application. You must go into the setup program and remove the delays. Caution, if you make any major configuration changes such as changing the basic function of the module or remove it and re-install it, the delay will return to the default 250 ms delay. Check the voter output module for delay as well.

Also, in the voter setup, not any individual module setup, there is a vote delay setting. This used to ensure all active receivers are up and ready for audio processing. This comes in great if you have some slow COR action on some receivers. Being this is a global setting effecting all receivers, it usually doesn't cause any problems such as echo unless you are somehow mixing or monitoring audio directly from the source and the Raven output at the same time.

You are correct in the statement that the Raven functions through the connected PC while the programming software is running. Raven decided to make the programming changes in real time. This means as you change levels or other settings, the results are immediately implimented. You MUST remember to write the changes to the Firmware before disconnecting or exitng the program software. I have experienced errors in the write process and lost all changes and had to start all over. Now when I make any changes, I write down the parameter setting so I can reference it if I need to redo it.

Also, be sure to close all configuration setting boxes prior to saving to the firmware or disconnecting the programming software. Some, but not all parameter settings will actually change and revert to a default value if you fail to save the setting and close the box prior to writing to the firmware. This drove me nuts until I figured what was going on. Raven is aware of this problem and has it on a list of stuff to fix.

Hope this helps.