Matthew Steel

At that size wrench, I'd say the 0.27mm could be significant. Seems like an undersized wrench might turn the screw if it is loose enough but then slip. I imagine you might be able to tell by feel if that is happening. I haven't had one of these open, so I'm guessing here - If your door operates properly and the XLR housing is firm, then I'd say there is a second screw that just holds the insert into the housing. I expect that second screw, if it exists, would be the standard flat head screw with reverse threads that holds all Switchcraft inserts.

I pulled the 0.1 spec from memory - the device I was thinking of was a 744T which when I actually looked it up is "< 0.2 ppm when tuned with an Ambient Master Controller." The master clock in my system is an original Digidesign Sync I/O. Its factory calibration spec is +/-5ppm but can be calibrated to within 1/3ppm. I have calibrated it as close as I can to my video group's 744T, which is probably not calibrated to anything particular but they trust it as accurate. I do relatively little video but when I do, drift can be significant. Some of the projects really do include long shots of live musical theatre where the only edit is for intermission. These single shots are typically a wide shot of the stage and/or an inset of a conductor camera. How drift is handled varies depending on the group dong picture: * One group gets a reference mix from me and cut picture to it. So they will adjust sync if needed, but less drift is better. * The other group attempts to keep everything in sync from the start. While they haven't exactly "complained" about drift, they have reported the varispeed ratio they used to align my audio to picture. It is for their sake that I have tried to get things as tight as I can.

I briefly met Gordon last summer when the family road trip included a stop at the factory. Short interaction but he seemed nice.

Dante clocking is very similar to using word clock, at least in the sense that every device must ultimately derive its clock from the same source. Dante has the nice feature that it can choose the "best" Dante device to be that source and all the Dante devices on the network will sync to it. So, in the scenario with a FOH board and Dante card, one must clock the other. Generally the recommendation I have heard is that the Dante network be the master for all other devices, including the FOH board, monitor board, etc. As I understand it the primary advantage is the ability to choose the "best" of the devices as clock master, and the fact that if the elected "Leader" device goes away the Dante network will elect a replacement and everybody will still get a clock signal without intervention and perhaps even without any audio interruptions for the remaining devices. However, the quality of the clock is a separate discussion from simply getting a clock. And, it is important to note whether we are talking about jitter (sound quality) or frequency accuracy (drift with respect to picture). I think @tourtelot may have been talking in the context of jitter, but the main discussion in this thread seems to be more a question of drift. Video equipment (and audio equipment targeted toward use for picture) typically has a clock that is accurate to within fractions of a part per million. On the other hand, typical FOH or studio equipment does not require that kind of absolute accuracy and the clock specs I have seen have been 10, 20, even 50ppm. Notably, I have never seen a frequency accuracy spec published for any Dante interface card for a mixer, or for any of Audinate's chipset modules. I haven't looked at all, but anywhere I looked the best I could find was a statement to the effect that the clock was high quality. Given that lack of information, I cannot expect that the ppm spec is any better than that of a good FOH board. So, @Philip Perkins concern seems valid to me. If the camera has a +/-0.1ppm clock, and the Dante audio is clocked by a +/-10ppm FOH mixer, then they may be jammed to the same timestamp at the beginning of a shoot but will drift as much as a frame per hour. Fine for some scenarios, definitely an issue for others.

If you are inclined to DIY, then for 75 ohm, try a coax whip like for wireless mics, with an appropriate length for the FM band; or for 300 ohm try a folded dipole like this one, https://hf-antenna.com/003/. I built a 300 ohm at one point for TV and it worked well enough, although the polarization is different between FM and TV (if that makes much practical difference). If it has no internal antenna, then I expect even a coat hanger would be a big improvement.

We still play our vintage USA version of Scotland Yard from about 40 years ago. The rules would need translated of course, but the game itself doesn't rely on language at all. It looks like the German version even keeps the British ticket type names so I expect the board is identical.

I have had good results with Dante on an Apple Silicon iMac. This was, however, with the Apple Gigabit Adapter in the power blob (probably Thunderbolt in some manner?) and not the same type of TB/USB device that would be used with a laptop. For example, for a recent live musical we did, I had 64 channels of Dante coming into the M1 iMac using Dante Virtual Soundcard. All but a few of these were recorded using Pro Tools running under Rosetta on Monterrey. The show was close to 3 hours long and I am not aware of any lost audio. The Dante traffic even was on a shared corporate network without QoS, although all the Dante devices were on a single switch and our stuff lives on its own VLAN. We did encounter the IGMPv2 problem mentioned at https://www.audinate.com/learning/faqs/mac-osx-shows-listening-under-the-clock-status-tab-in-dante-controller. Like most IGMPv3 devices, Apple's network stack will drop down to IGMPv2 compatibility mode if it sees an IGMPv2 packet. But it seems to stay there permanently. So if some IGMPv2 device ever appeared on the network, even briefly, the switches would drop down into compatibility mode. After a time if the device left, the switch would revert back to IGMPv3 but the Mac would not. The result was that the Mac would ignore the IGMPv3 multicast group queries, and the switch would drop it from the PTP multicast group. That would make Dante lose clock. The solution for our specific case was that our network guy set up the switch with a static subscription to the PTP multicast stream for that specific port. That way even if the Mac stopped sending IGMP group reports, the switch would still send the PTP packets.

I find that Lectrosonics HHa are a bit picky about AA batteries too. The Duracells they ship with fit easily. The rechargeables we usually use, on the other hand, are hard to get in. A closer inspection reveals that while both cells are the same length and diameter, the Duracells have a narrower negative contact than the rechargeables. That makes the rechargeables a bit to harder to tilt in. They fit, but I have to use more force than I'd prefer.

Does Professional Wireless Systems still help people do applications? They might be a middle ground between going it on your own and hiring an attorney.

It has to have a step up DC-DC converter to get 48v for the phantom. This is probably shared by all the inputs, so it makes sense that all inputs would be affected if the converter failed. A schematic would help, but chances are good that whatever circuit is there uses standard components and should be very similar to the reference design for whatever chip it uses.

Another possibility to consider is ultrasonic interference. The compander circuitry in the EW transmitters is known to be affected by ultrasonic sources like occupancy sensors for lighting. Mostly I expect it would sound trashy but perhaps the right signal could totally swamp the audio or mess up a pilot tone.

I think you missed his point. I can't tell if it was on purpose or for some other reason.

Although whoever manufactures it ultimately answers to Lectrosonics in some way, shape or form.

I agree. My standard pro-level live audio equipment have very loose clocks compared to video oriented gear - perhaps even +/-50ppm. When I work with video, especially long form events, I need a tighter clock to minimize drift. It was very helpful to be able to calibrate a master word clock to the video department's SD mixer using its word clock output.

It looks possible. Apparently the original NA Hybrid unit that was sent for FCC testing was set up this way. See pics of that here: https://apps.fcc.gov/eas/GetApplicationAttachment.html?id=2440322 Having had an LMb open, here is some advice: 1) Remove the battery door (together with its hinge/mount) to view the ribbon connector for the membrane switch pad, and then evaluate if you want to continue. 2) Disconnecting the membrane keypad's ribbon cable is fairly straightforward - flip up the black retaining bar on the connector (a plastic spudger or something like a toothpick should be good for that) and the ribbon will come out fairly easily. 3) With the ribbon cable disconnected, it is easy to see how to remove the top and the attached circuit board. 4) Reconnecting the membrane switch ribbon is a bit more difficult than disconnecting it. Hence the evaluation in step 1. The recommended tool is a pair of angled tweezers. I didn't have those but I was successful with needle nose pliers - but there is barely enough room for them in there and I felt like care was required and there was a slight risk of damaging the circuit board. Once the ribbon is in the connector, the retainer can be flipped down with the same thing you used to flip it up. 5) It is not necessary to remove the membrane switch pad itself. If you do, expect to replace it. The only thing under there are the screws that secure the plastic battery guide, and there is no need to remove that.

I was looking up some DPA specs today and found https://www.dpamicrophones.com/mic-university/how-to-properly-attach-a-dpa-microphone-to-a-wireless-transmitter The quote below from that page reminded me of this discussion. With Lectrosonics servo bias wiring providing typically 4v bias, the max SPL would be reduced from the 130dB spec to somewhere around 120-124dB. And, from the diagrams, the early stages of distortion at that bias voltage would not look like clipping either.

Wireless microphone operators with a Part 74 license are allowed to use 941–960MHz, except for a few frequencies reserved for other uses. Some frequencies may be permitted only when coordinating with local FAA officials. Unlicensed use is not authorized, so any products in these bands are targeted toward professional users eligible for licensing. In contrast, I believe the old cordless phones operated on an unlicensed basis in the 900-928 MHz range.

IR sync would solve this nicely. I can't think of a reason it wouldn't be an option except in a few edge cases. That way, even if the scan chooses a frequency in the overlap zone, the sync will ensure the Tx and Rx match. Incidentally, the compatibility mode and tuning step size also will be set to match. Since all your equipment is A1, it will not matter whether it is using 470 or 19 as long as both ends agree. The only difference is which channel number is encoded in the pilot tone. That has to match on both ends or the receiver will decide "not my transmitter" and will not unsquelch. If setting frequencies manually or via dweedle tone, you will just have to check the block. The whole 470/19 thing seems to me like the natural result of a series of decisions Lectro made over decades as technology advanced. When they decided to make devices that operated below block 19, they could have chosen to make them block 18 without an overlap. But then they still would not have been able to tune below 470.100MHz because of government regulations.

Seems to me like that would be possible. The VRMWB serial command protocol is similar, but not necessarily identical to the currently supported devices. That part is all that the app developer would need to implement. Since the original venue does not have a network port, the end user would need to set that up. There are there are several ways to tunnel the serial interface through a TCPIP connection, and Wireless Designer already supports that. The GlobalCache device in the Lectrosonics tutorial video is one option. The VRMWBs that I use are connected via USB to a Raspberry Pi. Internally the VR uses an FTDI chip, so a rule file can tell the Linux udev system to use the built-in FTDI driver and present the USB connection as a virtual com port. At that point a server like ser2net can make the VCP available over the network.

I just re-read my post and it comes across as if there is no hope. That's not what I meant to convey - absolutely call and ask. Or email if you must considering the time difference. Lectro will help if they can, and if they can't they'll tell you that.

The spec is not published as far as I know. Here are some notes based on my poking around. The only transmitters I have experience with are the LMb and the HMa, so the scope is limited. The IR sync is 38kHz carrier modulated by an asynchronous serial data stream. The serial data is 300baud, 8 data bits, no parity. Logic 0 is carrier present, logic 1 is carrier absent. The format of the data stream is as follows: <0x18><parm1>=<value1>;<parm2>=<value2>;...<parmN>=<valueN>#<CC><CR> <parmX> Description <valueX> (a decimal number) irblk The block number 19: Block 19 20: Block 20 ... 470: Block 470 606: Block 606 channel The channel number 0: Block base frequency 1: Block base frequency + 25kHz ... 1023 Block base frequency + 25575kHz compat Compatibility mode - NOTE: These are not the same as used by VRWB serial commands. 0: Passthru (not sure what this is, sounds dangerous to me) 1: 100 series 2: 200 series 3: Mode 3 - Sennheiser HiDyn Plus (Usable for EW G3 but Mode 6 may be better) 4: NA Digital Hybrid 5: IFB series 6: Mode 6 - Shure UHF, pre UHFR (Usable with Sennheiser EW G3) 7: Mode 7 - Audio LTD 2020/2040 8: 300 Series 9: EU Digital Hybrid 10: Mode 10 (possibly unused) 11: Mode 11 (possibly unused) 12: Mode 12 (possibly unused) 13: NU Digital Hybrid tuning Tuning mode 0: 100kHz 1: 25kHz other: 25kHz (probably a side effect) talkback Talkback on/off 0: Off (LMb seems to ignore) <0x18> is a start code - actually it is the ASCII "cancel" character, so it probably means to cancel any previous transmission and begin handling a new one. <CC> is a checksum, in ASCII hex, representing the two's complement of the sum of character values in the string. It does not include the initial start character <0x18>, the '#' character, the checksum itself, or the terminating <CR>. <CR> is ASCII carriage return (0x0D) Generally all parameters should be specified, although some combinations without all parameters may (at least partially) work. <irblk><channel><compat> works; combinations missing any of these generally fail to provide the expected result and usually generate an error message. I have reason to believe that in at least some models, any command that is permissible via USB would be accepted via IR. The only IR capable transmitters to which I have access are the LMb and HMa transmitters. I didn't find any additional commands for the LMb, and I don't have any notes either way about the HMa. All experience I have with the IR format is unidirectional (RX->TX) but something I read in a spec of some newer device made me think that newer devices may have bidirectional capability.

There appear to be several hardware revisions of the SMWB, and there are stern warnings to not to use the wrong firmware and/or bootloader for the version you have. So doing anything out of the ordinary is risky. Only Lectrosonics knows enough to tell you if it will work for your particular unit. The problem with that is that even if they know, they would not be allowed to tell you it will be OK. The NA compatibility modes were always illegal in Europe, and even in the US, where we are allowed to still use them on older equipment, as of October 13, 2018 it is illegal to manufacture new equipment to that older spec. That leaves experimentation at your own risk as the only option. Personally I would not risk bricking a SMWB to find out. So the safest thing to do is to use the transmitter as is and match the receiver settings to it. The latest receiver firmware can support either NA, EU or NU (which as far as I have read is identical to EU).

And consider live sound. Arguably the requirements of low noise are less stringent in that line of work as in studio or video production. Still, in one of the auditoriums where I work, a typical mic plugged in on stage goes through 7 pairs of XLR connectors. Almost all of the problems I have with connectors are attributable to the wear and tear after many years of plugging and unplugging cables.

Surprisingly it is still possible with Lectrosonics digital hybrid. At least, we use a consumer scanner marketed toward motorsports and whatever it uses (almost for sure plain old FM demodulation) is sufficient to have an intelligible signal that reveals at least big problems like a bad mic connection or clothes rustle.

If you want a look at the PCB without opening one up, there are internal photos with the FCC certification reports at https://www.fcc.gov/oet/ea/fccid In some cases FCC certification might depend on a non-removable antenna. If that is the case then such a mod would void the FCC certification. Obviously that would be one possible reason Lectro could not do it for you. I have noticed, though that for some devices with non-removable antennas, the model sent for testing had a removable antenna. The FCCID is on the outside of the case. If you want to guess at one without a device in hand, the grantee code for Lectrosonics is DBZ and the product code is usually some derivative of the model name. In the case of the SMa, it may well share the same FCCID as the original SM - since the (a) in the model designator indicated a change to servo bias input and might not have required recertification. Also, the single and double battery variants are electrically identical and share FCCIDs. There are separate IDs for different block ranges, such as (E)xtended, (L)ow, (M)id, and (H)igh.