Jump to content

Matthew Steel

  • Posts

  • Joined

  • Last visited

Profile Information

  • Location
  • About
    Live sound and recording for higher education
  • Interested in Sound for Picture

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. @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.
  4. 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.
  5. 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.
  6. 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.
  7. 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...
  8. 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)
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. Well, well, well. Anyone care to guess what showed up in the database yesterday?
  14. If there is one coming - and I expect there is eventually - it hasn't passed FCC testing yet. I don't see any new Lectrosonics authorizations in the FCC ID database (https://www.fcc.gov/oet/ea/fccid) since January 2019, except for the 940MHz variants and the DPR/DPRA.
  15. I expect you have already tried a different frequency, but in case you haven't, I have noted a few times that two transmitters on the same frequency will create interference that could be described as a squeal. I can't remember if it was with our Lectros or other brands though.
  • Create New...