open-headset-interconnect-standard / ohis Goto Github PK
View Code? Open in Web Editor NEWAn open standard for a common interconnect between headsets and radios.
License: Other
An open standard for a common interconnect between headsets and radios.
License: Other
Discussion has brought up that RJ-45 isn't a very rugged connector. Several alternatives have been proposed:
(To be clear: these are proposed as additional alternative standards, not to replace RJ-45. RJ-45 will remain the "default.")
https://www.neutrik.com/en/products/data/ethercon
Basically, an RJ-45 in an XLR shell. I like this for its backward compatibility. The only thing required in the standard is to mention that RJ-45 sockets could use EtherCON connectors instead, which would allow the user to choose EtherCON cables for ruggedized installs.
https://en.wikipedia.org/wiki/D-subminiature
They're ubiquitous, inexpensive, very rugged, and people know how to use them.
My concern with DE-9 is that there's no existing standard for paired pins. So it would have to be a shielded cable, or risk picking up noise in the mic line. Even with a fully shielded cable, there's the risk of cross talk between headphones and mic.
Add to the document the following:
http://www.arlancommunications.com/products/amateurRadio/radioSport/Headsets.asp
https://www.switchcraft.com/mini-xlr-connectors/?pg=1&mpp=96&n4=6
Chatting with David Bottom of Radio Sport, he STRONGLY encouraged use of the 6-pin miniXLR. It's an existing standard on headsets, is commonly available, and is very rugged. He's had very good experience with them.
The problem is they're only 6-pin:
It combines Headphone GND and Power GND (which isn't the end of the world; at least it keeps Mic GND separate), and it does not provide any power pin.
Add to the document:
https://www.switchcraft.com/mini-xlr-connectors/?pg=1&mpp=96&n4=8
An 8-pin miniXLR loses compatibility with the existing 6-pin standard, but allows us to remain electrically consistent with the RJ-45 "base" standard, and get all the other mechanical benefits of the miniXLR connector.
Add to the document:
The idea is that this device is a piece of test equipment, not needed for full time use. A club could have one for everyone to use to help them adjust their mic levels. Then, once adjusted, remove it from the circuit.
A common input voltage is 13.8v +/- 15%. But OHIS uses 5v as its Vcc.
Using an LDO will dissipate up to 2W of heat. Not desirable.
Design a switching buck supply:
Use RFC 2119 key words in the standard description and mark them as such to remove ambiguity for people not familiar with usual RFC wording.
Formalize the OHIS logo and add it to the standards doc.
eg: QST, CQ, RAD COM, etc.
Got a very good email from Elliott L, W6EL, who makes the following points (I'm paraphrasing since I don't have permission to paste his actual email publicly.)
His concern is having an actual coaxial shielded mic line inside the bundle of other signals (specifically headphones), not just having a single shield over the whole bundle which would allow cross-talk between the headphones and mic lines. And building such a cable in a Modular connector is pretty much impossible (I agree with that.)
However, I strongly disagree that GX16 is the correct connector to use. I don't want to make YET ANOTHER INCOMPATIBLE use of that connector. Also, GX16 connectors are a royal PITA to acquire for use on PCBs (as me how I know).
Instead, OHIS already specifies the DE-9 as a Rugged connector option. I believe it addresses his expressed concerns (easy to solder coax to, easy to make custom cables) and addresses my concerns as well (not already a standard in audio, commonly available, still rugged (GX16 is as well)).
I've responded to Elliott with my counter argument and am seeing whether he has any further concerns, or a rebuttal.
He's absolutely right. Specify a ripple limit, and frequency.
His concern is that different radios will have different level outputs, and that should be standardized.
I understand his point, and maybe the standard should be more clear on what "headphone level" is. It's currently specified as 0dBV into 16R load. Is this "correct?" Is there a better way to specify this? This is a low-impedance spec; what about high impedance cans that might require more voltage, but less current? What THD?
It's also not clear that that's for max volume. The ACTUAL listening volume is adjusted by the Radio device, not by the User device.
He's absolutely right. Specify max pull-up voltage, min sink current capability, and max forward voltage drop. Make sure that specification works with BJTs, FETs, Optoisolators, contact switches, and relays.
Design a mic pre-amp to connect a dynamic mic to device expecting an electret.
I think this can be done using the bias power on the electret mic feed:
R2 and C2 are part of the device consuming the Electret mic. The node between R2, C2, R1, and T1 is the "mic" pin on HIS, and ground is "mic return". This only requires C1, R1, and T1 to turn a dynamic mic into an electret level signal.
...we just need to, ya know, pick R1 and T1. (C1 is likely to be a 1uF ceramic.)
HIS will specify standards, but will also allow direct connection to a radio that's already expecting an elecret element. So R2 and the voltage are likely to be all over the place.
5vDC Bias through 2.2k is WAY TOO HOT for every radio I've used it on. Below is an example of what I measured by another radio.
With the FHM-3 hand-mic plugged in, the Flex 6400 has 1.8vDC at the Mic connector port.
Internally, the Mic+ goes through R1, a 2k series resistor, then branches two directions:
The DC voltage across R1 is 1.10v (0.55mA), and the DC voltage across R2 is 0.70v (0.35mA). This means there's .20mA across the sum of leakage current on the caps, and through the electret mic element.
I don't know what the internal-to-the-Flex resistance and supply voltage are, but given the 0.55mA total current measured above, these are the common combinations that would work:
Wait a sec, the "way too hot" here is the headset mic going straight into the Flex. This isn't my Electret driving circuit. I'm still filing this ticket to document the above stuff about the FHM-3.
A common problem that all OHIS manufacturers will run into is the lack of availability of audio taper trim pots, for use when matching levels between OHIS and devices.
AI8W suggests putting a fixed resistor in parallel with a linear pot to get a somewhat-not-really logarithmic taper. I'll research that and see what it does. (Easy to simulate, but I suspect someone already has done that.)
The other idea I came up with is to split the 10/90% audio taper into two separate pots stacked on top of each other, one 1/10 the resistance ("fine") of the other ("coarse"). Take the output from the sweep of the Coarse pot, and tie the sweep of the Fine pot to the midpoint between the two pots. For adjustment, turn the Fine pot all the way up, and use the Coarse adjustment to find your volume. If with the coarse all the way down it's still too loud, then start adjusting the fine.
So you can convert from line level audio to OHIS. Both directions:
Bonus points for including DC isolation: with audio transformers, or caps, or similar.
DrCampy: Hey, how are you doing?
I'm finalizing Module17.
I remember that we discussed how to implement OHIS on the board.
I also realize that the current implementation is a notable deviation from the standard, so I'm not sure that it is a good idea to keep it as-is...
Most notably, the audio output we provide is the one that normally goes to the speaker. So the amplitude is up to 5V. But your document says that it is expected to be between 0dBV (1V) and -10dBV (300 mV).
And if I want to stay close to 1V, I could repurpose one of the free operational amplifiers already on the board, but it is only able to provide a few mA (25 mA iirc) so it would not be able to power a load as low as 8 Ohms... . Also, it would be ground referenced but with a DC offset. If I want to cancel DC offset, I would need to put a DC-blocking cap but then, my low-pass cutoff frequency would be terrible if we must support up to 300 Ohms as stated in the standard
I need to know what you suggest for that. Also, maybe the standard needs to be more precise about what is acceptable (in terms of acceptable loads mostly).
Mark: Output: Just put a resistor in series, and that'll be fine. I'm trying to figure out what value. Probably something between 100R and 33R. I know my stereo at home powers the headphones by just putting a 220R in series from the 100W speaker output! If you do the math, it actually comes out pretty close.
DC blocking: Yep, it's about 100uF or more. And yes, it needs to be there.
I usually put 220uF or 470uF on stuff that I want to be full range. For communications range, you can probably get away with 47uF (that's a guess, not actual calculation.)
And the low cut-off point goes DOWN (more bass) as your load impedance goes up. It's not able to discharge the cap as quickly, so the cap is able to pass the lower frequencies better.
It's the 8 ohm side that you need to be worried about.
An 8 ohm load drawing through a 100uF cap has its -3dB point at 200Hz. That's probably fine for this use case.
So, put a 100uF cap in series from the power amp, then two 33R resistors off the negative side of the cap toward the Left and Right channels on OHIS. They'll serve dual purpose: Allowing one headphone to get shorted to ground without killing the other, and they'll brint a 5v (did you mean watt?) signal down to about right for headphones.
put a 100uF cap in series...
No, it is indeed up to 5V signal (5V peak). Output power is 1W max
Thank you for the feedback, I ll crunch some numbers tomorrow and tell you what ๐
Also, I'm afraid that with serial resistors, I will have way more than 0dBV with higher impedance loads ๐ฌ
Mark: The good news is, high impedance loads can handle the voltage better and will actually need it.
DrCampy: Yes, but then maybe you should update the document with the standard to provide some guidance? And also include more details about the acceptable voltages wrt the impedances ?
whew! that's a lot of copy and paste.
The OHIS spec calls out
The Microphone signal is a typical electret microphone signal: -45dBV +/- 3dbV into 600 to 1k ohm
Then goes on to describe the amplification needed for a dynamic mic
I wonder if later in the spec you could outline the intent and methods for achieving those levels, for example the reference circuitry.
Are these dBV measurements measured as Peak voltage or RMS?
Do you have any feedback on how to reliably generate audio into the mic to verify those levels? Or would you ultimately expect the end user to verify audio levels with signal reports and adjusting mic gain settings?
I think I noticed a mic level adjust pot on the Halibut user adapter product. I was curious how a "OHIS compliant/calibrated mic setup might vary from user to user based on talking loudness and mic handling (distance from mic, etc)
Then an end user could use a VU meter (even a few leds or an led bar segment, similar to an audio compressor meter) could help provide visual feedback that mic levels are appropriate for their hardware and talking style
Not so much an issue as a proposal. Could the standard also include a pinout for a CW keyer rather than a mic? Folks might like, (I suspect very much), to bring their own keyer as well.
I've built up a prototype of this idea at hcarter333/rockmite#6
Thanks very much for putting together the standard! It inspired the work I did above. Also, if this isn't appropriate place for this question/suggestoin, please let me know, and I'll close or delete the issue. Thanks again!
73 de KD0FNR
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.