Matthew Steel

You only mentioned the Venue and one Sennheiser receiver. If that is all you have, then I would just feed the Sennheiser from the antenna out port on the venue, as long as the frequency band of the Sennheiser and the VRM overlap. If you are using the ASA1 to power the Sennheiser receiver then you should be able to just power the receiver directly instead. I think only Lectrosonics could give you a definitive answer about your actual question, but: * If the Venue is jumpered to provide power to an antenna then bad things would happen as the two power supplies "fight" against each other. * If the Venue is not jumpered to power an active antenna, then probably the Venue would be OK. The same circuitry that would block the Venue's own power output from being a problem to the RF input would probably also block the Sennheiser power coming in.

Marvel's Agents of Shield have a Behringer something or other, presumably taking readings on the Kree monolith. The logo isn't visible in the linked still, but in the episode the camera pans across and the distinctive triangle logo is clearly visible on the top piece of equipment in the rack. https://static.wikia.nocookie.net/marvelcinematicuniverse/images/6/69/Fitz_Gun.png/revision/latest?cb=20151001231247

I only have experience with MKH40's but on those the XLR is rigidly connected to the inner frame, as is the capsule. So, if the MKH50 is the same way, then as the XLR is pushed into the metal tube/body/shell then the grille/capsule will slide out the same distance on the other end. Look for that gap at the capsule end and see if it will slide back in to get the screw holes lined up. On the MKH40 there are springy metal strips on the inner frame that make contact to the outer tube. I have seen at least one case where an end of one of those had come loose. It would catch on the inside of the tube making it difficult to get back together. I'm not sure if it was originally soldered or welded, but my soldering attempt appeared to be successful and then I was able to get it to slide back in.

This is a totally different direction, but would a good podium mic meet your needs? I could not recommend the sound of the Shure or AKG podium mics I have worked with, but I have some experience with the Countryman Isomax 4rf and it sounds reasonable, especially for the price.

I think you will still need something like diodes to isolate the two batteries, but using one battery at a time should be a workable strategy. The diodes will drop about 0.6v which will equate to some small amount of lost power. Even with two different types of batteries, as long as they are the same nominal voltage things should still work. Run off the first battery until is nearly discharged, then add a fresh battery to the empty slot. At that point the fresh battery will take over the entire load because its voltage will be higher (and the diode will prevent it from charging the spent battery). Then you can remove the spent battery for recharging.

If the IFB just needs to be listenable and not pristine, then you may even be able to keep the transmitters in digital hybrid mode. Come to think of it, you'd probably need to disable pilot tone on the receiver for this to work. We use our transmitters in NA and NU digital hybrid modes and we also use a Uniden scanner to monitor them. The scanner is a consumer model marketed toward motorsports fans, and I'm pretty sure it is just doing straight FM demodulation. I think the the digital hybrid signal includes as an FM component that is a prediction error. So, the scanner is not picking up "the" signal, but it contains enough information to hear the mic and to detect many types of problems.

Thanks, @PMC Since my location doesn't change I only scan periodically to look for changes in the environment. I use Shure Wireless Workbench for coordination since it supports lots of different manufacturers out of the box. I don't think I could get by without WWB's zone features. I can define zones for different buildings, etc. I try to make it so our portable systems and media groups can power their stuff on any time, anywhere on campus and "just work" without changing anything, but that small systems far away from each other can even use duplicate frequencies if need be. Things have been quite reliable. That's why I want to make sure any additional telecom equipment doesn't ruin my life

Thanks for your comments, Larry. I think you would approve of the multicouplers I have in place. I haven't spec'd all of them on campus, though....

Does anyone here have insight into operating wireless systems in close proximity to high power transmitters? Or any fanatical RF gurus willing to chime in about the potential risks? I am a staff audio engineer at a university, and I have become the de-facto RF coordinator. I keep track of over 100 UHF wireless systems spread across our 225 acre campus. I have been asked about the impact of potential telecommunication equipment installation (e.g. cellular antennas) on buildings. The information I have does not specify frequencies or technologies, so I have to assume "telecommunications equipment" could include traditional cellular 1GHz and up, 600-700MHz band cellular, and even TV whitespace devices (or even other technologies of which I am not yet aware). My first inclinations are: * Cellular > 1GHz would generally not be a problem since it pretty far away from UHF (and we don't operate any 941 band devices). * Cellular in the 600MHz and 700MHz bands might require us to be more careful about filtering on our antennas, particularly where we have wideband multicouplers in use. * TVBD or white space devices would be a big problem since they would be right on top of us. The part I am not as well versed in, is intermodulation inside the transmitters themselves where a high powered transmitter might be within a couple hundred feet of a location. A quick estimate with the inverse square law leads me to believe that if a 50mW transmitter could generate problematic intermodulation in another transmitter at 3ft, then a (typical?) 100W transmitter would be a similar problem at 136ft. Real world issues like directional antennas, intervening structures, etc. could help with that but that seems like it actually could be a potential issue. Thanks for reading and for any insights you're willing to share.

The problems I have heard about with occupancy sensors don't involve RF. Rather some use ultrasonic signals as the detection mechanism. These signals, though inaudible, can be quite strong and can be picked up by a microphone. In certain transmitters, the low pass filtering on the input is not sufficient to prevent the ultrasonic signal from having an effect on the compander stage. This creates artifacts that show up in the audible frequencies.

I don't think that would work. The Betso runs on a single AA battery (1.5v) and the Lectrosonics L series would run on 3.0v with their two batteries in series. The Lectrosonics SM form factor transmitters, on the other hand, do run on 1.5v, with the two-battery versions having the batteries in parallel rather than in series. So maybe the corresponding BattElim would work.

I didn't see a battery eliminator for the LMb listed on the Lectrosonics site either. I realize for you the time zone difference is significant but you might try calling Lectrosonics to see if the battery eliminator for the LT or LR could be made to work. It appears like they would be electrically compatible but it also appears the screw holes don't match up. Besides the curved vs square battery door shape.

Have you tried changing frequencies to see if it makes any difference? And of course, have you run an intermodulation calculation on your frequencies?

I have used some Lectrosonics 185 systems regularly over the years, not so much recently. They generally did the job but had some drawbacks. Some of the drawbacks are inherent in the frequency band, others would depend on the specific equipment. Another limitation was related to FCC regulations of the time that have recently been amended to improve things. Inherent in the band: 1) Low frequency means large antennas. For receive antennas we had large Yagi antennas installed in one location and used coax whips other places. The Yagis were reliable, the whips less so. On the transmitter side, however, the microphone cable shield was the RF antenna, and so care had to be taken that the cable stayed relatively long and straight for best performance. This is probably a reason much of the VHF use today is IFB or similar. Specific equipment: 2) Most systems were fixed frequency. Not as flexible for avoiding other users, but on the upside, it did allow the RF design to incorporate tighter filtering which was good for performance. 3) No diversity. I'm not sure how big a problem this really was, but it did seem that we'd have places with nulls and I expect diversity would have helped. Regulation: 4) VHF systems were (and still are to some degree, I believe) limited to a handful of specific channels. Originally, the allowed frequencies had been chosen without much (any?) regard to intermodulation in multichannel systems. Regulation changes that took effect with the 600MHz auction introduced a new coordinated frequency set that is better for operating more systems simultaneously.

I have a DCR15/1A6U (supply for Venue 1) here on my desk. The plug on that looks like what you describe: Barrel outside diameter of 5.5mm and center pin socket diameter of 2.1mm. I too would be glad to hear an official spec or even a recommended part number. I was trying to find a compatible panel mount - making something I'd like to be compatible with the extra Lectrosonics wall warts I have lying around.

@jawharp, the IR sync format is not the same as the audio dweedle tones. However, it is a fairly simple protocol that uses a standard 38kHz IR frequency and modulates it with 300 baud asynchronous serial data. Unidirectional only. Yes, Raspberry Pi GPIO has enough current drive capability to supply an IR LED.

You may want to check out rabbitears.info. It is geared toward TV reception, but it has a lot of information that is useful for wireless microphones. The "Signal Search" tool in particular is very similar to the way I remember the old Sennheiser tool.

It's been a few weeks, so maybe airing them or other things you have tried have been sufficient. I just wanted to mention that I bought a house where the previous owners smoked. The real estate agent provided us with an ozone machine. We closed up the house and left it unoccupied for a weekend with the ozone at its highest setting. It seemed to help. I won't speculate on what ozone would do for microphones, though.

This is important so I am putting it into a separate post. Experimenting with these commands is dangerous, as commands to not always do what you might expect. I will use the "block" command as an example, because you mentioned it in your file as writable, and I messed something up myself doing exactly that. Documentation for the command in the context of the VRM(WB) - which is block based, and doesn't know the concept of the 3-block bands - indicates that: * The query form of the "block" command, without parameters, reports the block of the receiver frame * The query form of the "block" command, with a receiver designator (1-6, or * for all) reports the block(s) of the corresponding receiver module(s) installed. * Note that for the VRM(WB) the "set" form of the command is not documented, and indeed makes no sense for a user in this context. However, it is entirely possible that the write form of the command may exist and could be a mechanism for configuration at the factory. Now move to another device, the HMa. Serial commands for this device are entirely undocumented, but they do exist through the USB interface. Since the HMa is a band-based device, and setting the channel requires you to also set a block, you might think that the "block" command would be a mechanism of tuning the transmitter. But in fact, the "block" command in the HMa works just like the command does in the VRM(WB): * The query form of the "block" command returns the base block of the unit's band. So, an HMa A1 will report block 470. * Setting the "block" parameter WILL RECONFIGURE THE FIRMWARE to use that block as the base of the tuning range. I know this by experience. In my case I was working in block 20 and in my experimentation I believe I must have sent the command "block=20". Everything appeared fine. But months later, I had cause to change the frequency to somewhere in block 470. I found that the transmitter refused to tune below block 20, even though it was an A1 unit. I called Lectrosonics and the tech there told me it needed to be sent in to the factory. After a bit of thought I guessed that my previous experimentation might have caused the problem. I figured it was worth a try to reverse my mistake. After all, I was about to send it in anyway. Setting the block back to 470 appears to have corrected the problem. When the tech followed up with me I told him what I had done and that it appeared to work fine now. I got a response something like, "I have no idea where you might have gotten the information you used to do that fix. That is certainly not something we at the factory would have given out. You could have bricked your unit." So, long story short, BE CAREFUL.

I looked again, and "su" does not appear to apply to the SRc. The following additional commands "should" be there though. I expect many of them exist for factory setup and/or testing and as such will either be boring or dangerous. "buttons" - I expect an instantaneous status of what buttons are pressed. "lockdet" - something to do with a PLL lock? "divtest" - sounds like "diversity test" but what exactly that means... "extvcc" - wouldn't be surprised if it was a power supply voltage "rpixel" - screen testing, perhaps? "windet" - sounds like it may be a status of a window detector circuit of some sort...

As for your missing commands, I don't have an SRc but my sleuthing tells me the following commands should exist: irsend pilotbp ameter (should be an audio meter value) txbatt (should be transmitter battery status) rmeter (should be an RF meter value)

The online help in Wireless Designer contains a section on serial commands. I don't see anything specific to the SRc, but there are sections on Venue1, Venue2, DR, DSQD, M2T; and the commands from one unit to another generally follow the same format. Note that command reference in the online help does not appear to have been updated to reflect all firmware changes. For example, the Venue1 "channel" command is documented as taking a parameter from 0-255 for 100kHz steps; but the command actually takes a parameter from 0-1023 for 25kHz steps. If the SR is like the Venue1, you might enjoy trying the commands "su?" or "p". On the Venue1 these undocumented commands are used by Wireless Designer and provide an "ASCII-compatible-binary" version of the complete setup and status respectively. But be careful - it is possible to break things by writing the wrong thing to certain parameters.

As far as the memory full issue, most Android devices (maybe even all, even the cheap ones) have a micro SD slot. That could make it possible to swap out media pretty quickly.

I don't know if it would be worth Lectrosonics' time to make a device like that but I wanted the IR sync capability bad enough that I made a DIY IR sync device. I built several to support the 10 VRMWB racks we have. The devices do not integrate with Wireless Designer. Essentially they are a Raspberry Pi with an IR LED and ballast resistor and connect to the VRMWB connects via USB. I set it up so that to trigger an IR sync all that is required is to press and hold the Venue front panel select button corresponding to the receiver you want to sync. I'm fairly proud of all the features I've put into them, like: * Scan function that generates a CSV scan file suitable for import into Shure's Wireless Workbench * Frequency deployment to the Venue receivers using CSV format coordination report from WWB. * IR sync from Venue receivers to LMb transmitters. * In one location, automation between the Venue, an audio recorder, and a digital console. The software end of it has some significant hard coding so it is by no means a turnkey solution. But if you want to embark on your own DIY version let me know and I can give you some key information.

You didn't say how you chose your frequencies, and nobody else has mentioned intermodulation yet. So if you haven't run a calculator on your frequencies yet it would definitely be something to check.