I have a DMK URI that I am trying to interface to a Yaesu VXR-7000 . I followed this previous thread here , URI Hook up for Yeasu VXR-7000 (Angeo and Kevin) and followed Kuggie’s suggestion on how to wire the DB25 from the rear of the repeater to the URI. However, the link that provides the instructions on ASL configurations is dead. I have searched the net looking for more info, but they keep pointing to that same link. I know I am only supposed to have “remote” turned on in the front, and that doesnt do anything. When I try to press repeat on the front, the repeater does repeat, but has a horrible hum on the receive radios. When I unplug the Cable from the back of the repeater, the hum goes away and acts like a standard desk top repeater. I am using the latest distro that is on the ASL site now as this is a new server and node I have created for our club. When I try Radio Tune menu, it tells me that USB Radio must be enabled in modules (which it is) and selected in Rpt.conf (which it is) then fails to run. Please help. Thanks
I’ve restored the example configuration files on the Masters Communications server.
http://www.masterscommunications.com/temp/2302/
Kevin W3KKC
Sounds like usbradio isn’t fully turned on in modules. Did you turn off simpleusb, as I think you can only have one or the other enabled at a time (not sure about this)?
Also - how old is the URI interface? Is it a URIxB? If so, all bets are off for any of this to work at all.
Kevin W3KKC
It doesnt say URIxB on it anywhere. And the P/N on it is 9095. But its still a no go. And the USBradio is the only module set to load. Simple is marked noload. I am using a pi if that makes a difference
Of course when I enable Simple and no load USB and change it on RPT , that at least lets the tuner work, but when I switch it back to USB and put simple on noload , and change it on RPT, it tells me USBradio must be enabled when I try and run the tuner. I’m at a loss
noload => chan_simpleusb.so ; CM1xx USB Cards with Radio Interface Channel Driver (No DSP)
noload => chan_sip.so ; Session Initiation Protocol (SIP)
noload => chan_tlb.so ; TheLinkBox Channel Driver
load => chan_usbradio.so ; CM1xx USB Cards with Radio Interface Channel Driver (DSP)
noload => chan_usrp.so ; GNU Radio interface USRP Channel Driver
noload => chan_voter.so
make sure you also have /etc/asterisk/usbradio_tune_usb_YOURNODENUMBER.conf file configured properly. Yes you may leave both chan_simpleusb.so and chan_usbradio.so enabled in modules.conf and simply select which one with rxchannel= in the /etc/asterisk/rpt.conf file.
My first concern would be the hum. Something is wrong with the wiring between the URI and the 7000. There should not be any hum no mater the AllStar settings. Check your wiring, make any needed corrections and maybe all your problems will disappear.
I used Koogies Wiring diagram from the other thread :
There’s a DB25 male connector that plugs into the Vertex VXR-7000. And, there’s a DB25 male on the other end that plugs into the URI.
On the repeater end I have the following:
Pin 1 = shield = GND
Pin 6 = white = DISC OUT
Pin 12 = orange = EXT PTT
Pin 13 = black = GND
Pin 24 = red = TXD LOW
On the URI end I have the following:
Pin 1 = orange = PTT
Pin 13 = shield = GND
Pin 19 = black = GND
Pin 21 = white = MIC_AC
Pin 23 = red = RIGHT_OUT
When I put it back through the Cat250 controller, it works fine, no hum.
/etc/asterisk/usbradio_tune_usb_503290.conf file is empty. It is there , but nothing in it.
My rpt.conf settings :
; Enable the selected channel driver in modules.conf !!!
; rxchannel = dahdi/pseudo ; No radio (hub)
; rxchannel = SimpleUSB/usb_503290 ; SimpleUSB
; rxchannel = Pi/1 ; Raspberry Pi PiTA
rxchannel = Radio/usb_503290 ; USBRadio (DSP)
; rxchannel = Dahdi/1 ; PCI Quad card
; rxchannel = Beagle/1 ; BeagleBoard
; rxchannel = USRP/127.0.0.1:34001:32001; GNU Radio interface USRP
I stated in the original message, radio_tune_menu closes after it tells me that USB Radio must be enabled in modules (which it is) and selected in Rpt.conf (which it is) .
I have even formatted the memory card, re installed ASL 1.01 current version and ran it again. Still wont open radio tune for USB even though its enabled in modules. When I try to copy the file usbradiotune _xxxx from another repeater I have and change the node # it tells me it cant convert sound to 16 bit or something like that
URIxB cannot be interfaced to a VXR-7000?
The context of the original question in 2019 was using a URI (not xB) with a Vertex VXR-7000 and the usbradio channel driver. Because of a multitude of reasons, I don’t recommend any interface that has a CM119B to be used with usbradio. If you’re using simpleusb - then it’s fine. The URI and URIx both used the CM119A, which is significantly different when used with app_rpt. If you’d like to know why - I’ll fill in the blanks.
Sure, I’d love to know.
Also, I have a URIxB and the VXR-7000, I did the COR plus CTCSS signal mod on my VXR-7000 and wired repeater Acc 10 to URI 8 COR_DET and I still don’t get any RED when I key in. Am I confused and is this “COR” mod only for when receiving? Because using TXD LOW Acc 24 on repeater up to URI 22 LEFT_OUT and using REMOTE switch on VXR-7000 works great and it’s loud vs using TX AF IN (repeater Acc pin 3)
My issue is my repeater is not turning the RED led on when I either key in or I receive transmission on my repeater’s RX frequency.
In my humble opinion - the CM119B as it’s used in ASL has lots of issues. Anyway - here goes… I apologize - it’s long.
In October 2018, DMK Engineering contacted ASL and told the admin team they were moving to the CM119B because of the reported EOM (end of manufacturing) for the CM119A. DMK didn’t do much testing because the datasheets say the B is a direct replacement for the A, and C-Media’s datasheet would lead you to believe there are no drawbacks. After a lot of DMK URI’s with the B chip were produced (the URIxB), folks started complaining about “issues”. People were mainly complaining about low audio on both the RX and TX, and a total loss of audio if the TX mixer was set to a value less than about 375 when using any ASL distribution. There were also some grumblings about distortion.
Besides the RX and TX audio level issues, there are two other big differences that mainly affect the usbradio channel driver and its operation. One is the lack of quartz crystal stability, and the other is a new ‘feature’ called Pop Filtering on the MIC input. In review of the spec sheet for the CM119B in comparison with its prior counterparts (CM108, 119, and 119A), the pop filter (when enabled) rolls off the low end response enough that CTCSS detection of lower tones could be unreliable when using the usbradio channel driver. I’m also concerned that without the crystal time base, the RC time base stability of the CM119B will result in unreliable CTCSS detection because of data sample shift. I’ve exhaustively tested the CM119B in the DMK URIxB produced before January 2019. It didn’t work as a direct replacement of their prior units. The audio output was drastically different (lower), where a setting of 450 on the TX now needs to be toward the top of the setting (999) for a similar output level. I was asked to do this testing and work with the ASL admin team to come up with a fix. Here is a summary:
http://www.masterscommunications.com/temp/CM119B/urixb-testing.html
For those willing to navigate manually - here are some sweep graphs:
http://www.masterscommunications.com/temp/CM119B/
So - at this point in time - we had four big differences:
1, The lack of crystal stability - it’s a RC time constant (supposedly).
2, A new “feature” - a high pass filter intended to eliminate popping of some syllables like “P”.
3, A software attenuator/boost setting of 12 dB and 22 dB for the RX audio that’s ‘flaky’.
4, Even though the datasheet says the MIC input is more sensitive, it’s not, at least not with our current driver set. This greatly affects the RX level, as it’s really low compared to a CM119A (or prior chipsets). As a result of the testing above (in 2019) - I recommended some hardware changes to DMK that allowed the B model to have approximately the same RX audio level with similar mixer set values. HamVoIP went to work and solved most of the TX audio level setting issues that are based upon a different scaling structure. More on these below…
Without the crystal stabilized time base, the RC stability of the CM119B will result in unreliable CTCSS detection caused by frequency sampling drift. This is especially true in systems where the audio adapter is subjected to wide ambient temperature changes, as found in shelters that are not environmentally controlled - resulting in bit-slip.
A high-pass “pop” filtering exists on the MIC input (RX audio path), and is supposedly enabled by default with or without an EEPROM. In review of the spec sheet for the CM119B in comparison with its prior counterparts, the pop filter rolls off the low end frequency response. Some documentation claims 100 Hz and some indicate 80 Hz. This roll-off slope can be enough to cause unreliable detection of CTCSS when using the usbradio channel driver, especially on lower tone frequencies. Commanding the pop filter on/off is done from flags in the optional EEPROM. It was recommended to DMK to make the EEPROM standard (it was an option) so this feature could be commanded off, and that setting reliably retained as the adapter was plugged and unplugged from its host. Unfortunately - if someone wanted to use the EEPROM to store the “radio tune” mixer set values (the original reason for a EEPROM) it blew out the programming necessary for the B chip to work. This resulted in several bricked URI’s needing to be sent back for reprogramming - so they’d work again. Eventually DMK started making all URIxB’s with EEPROMs and the problem was resolved - unless someone wanted to save their configuration to the unit.
In addition to these items, there are audio scaling differences between the prior chipsets, and the CM119B. The scaling differences are causing audio level and quality issues that are not found in the prior CM108 thru CM119A based chipsets. To fix the RX level issue, DMK was advised to change the value of attenuator resistors (R5 and R7) to reduce the attenuation from 87% to around 35%. This was done by changing the “through” resistor (R5) from 470k to approximately 39k. This hardware change was necessary to make the receiver audio levels the same between the URIx and the URIxB (CM119A to CM119B). This was done so the code didn’t have to change to keep the receive levels the same between the two versions of the URI adapter. The original URI and URIx with the CM108 and CM119A use 87% attenuation between DB25 pin 21 and pin 27 of the CM-1XX chip. DMK is now using a 39k in position R5, and that reduces the MIC_IN attenuation from -18dB to about -3.9dB for the CM119B. Audio from the DAC is also reduced as compared to the CM119A and the level setting is much more granular, even though the number of mixer set steps are the same. While a hardware change fixed the level issue, audio quality issues remain. While I haven’t taken the time to quantify this, many people say the audio quality of a CM119B isn’t as good as a CM108 or CM119A. Maybe they’re using an adapter that has “pop” filter turned on by accident?
In digital systems like VARA FM, the roll-off of the lower frequencies might make it harder to properly detect data because of waveform distortion. This distortion comes from limiting the digital information due to the undesired analog bandwidth reduction.
Besides these issues, the level of boost (a function of an amount of attenuation, and the lack of it) is a commandable feature that is also EEPROM based in the CM119B. The standard functions of enabling and disabling seem to work correctly; IE both RX and TX boost commands work as intended in AllStar, but the software needs to be rewritten to command the “amount of” options from the application. There is a bug that if RX boost is set to the “22 dB” setting (as opposed to the original/only 12 dB option in the CM119A), there is NO audio passed through the radio interface. This is likely a channel driver issue with AllStar, and might not happen with other applications and operating systems. To make maters worse, these EEPROM commandable settings are only visible / changeable with a special software from C-Media. I was able to obtain it because of my production of the RA-Series radio adapters (I’m also an approved manufacturer), but it’s not available to the public. This means anyone wanting to build their own radio adapters, or initialize the EEPROM, or save their “Radio Tune” settings using the CM119B may not be able to command these features to the setting they want (or need) for the application(s) to work correctly. Of course, if you initialize the EEPROM or overwrite it by attempting to save your radio tune settings (the EEPROM’s original job), you blow the settings out of the EEPROM required by the CM119B and it fails to operate correctly and will need sent back to the manufacturer to be reprogrammed.
Some manufacturers like TechNo By George aren’t including the EEPROM with their B chip interfaces, so who knows how these functions get initialized when connecting their adapters to the host computer. It was found that these functions were set randomly if the EEPROM was not present and the radio adapter was plugged and unplugged from its host.
As if this isn’t enough - performance (or lack there of) is also a concern. The pair of USB impedance matching resistors on the CM119B should be changed to 39 ohms (compared to 22 ohms on prior chipsets) but no one is doing that. This results in higher USB noise on the device lowering the S/N ratio. The CM119B doesn’t require a USB pull-up resistor (usually 1.5k) and I’ve had to tell several manufacturers not to include it. One problem is some of the data sheet is conflicting and outright misleading. To make matters even worse - there are different data sheets available on the CM119B! C-Media would lead you to believe the CM119B is a direct “drop in” replacement for the CM119A - but nothing is farther from the truth. Especially when the manufacturers aren’t being told what is really necessary to make the B chip perform like its siblings.
We have certainly verified that an EEPROM is necessary to hold the settings of Pop Filter (off) and Boost Mode 1 (12 dB), otherwise bad stuff is going to happen. The pop filter setting is probably unimportant for people using simpleusb, but for usbradio or digital communications, enabling it isn’t good. Randomly getting the 22 dB boost mode will result in randomly losing audio. What’s weird is some people say you don’t need an EEPROM with a B chip. Really?
DMK reported that when they use the special Windows software to set the flags appropriately, then use URIDIAG (a program that tests the URI) that some of the levels at some frequencies (like 700 Hz) were “off”. Then, DMK reported that if they used URIDIAG to “initialize” the EEPROM (which was done for some reason like setting its unique serial number), it seemed to blow the EEPROM and the Windows software could no longer read it. It was recommended by ASL that DMK only set the appropriate flags with the Windows software and then use URIDIAG to “verify” the URI worked correctly; and not do any more initialization of the EEPROM. Unfortunately, if a user tries to save their radio tune configuration into the EEPROM (its original intention), that also blows the configuration out of the EEPROM and the CM119B will no longer function correctly. This generally requires the user to send the radio interface back to the manufacturer so it can be reprogrammed. Remember, the software to program it isn’t publicly available.
The bug where the CM119B loses audio if the mixer set value is set to below “375” is probably due to the audio “steps” not aligning in the channel drivers, but this is where we need someone that has a better understanding of the code and drivers. ASL coders did some work and attempted to fix some of the TX level issues, but it didn’t really seem to work as anticipated.
The audio scaling seems to be “off” and that’s probably why audio just disappears and is very granular, but who knows - I’m not a coder. HamVoIP went to work and solved most of the audio level setting issues. I suppose it works correctly - but I haven’t exhaustively tested a B chip with HV.
In summary, and IMHO, the CM119B is a train wreck. C-Media produced the CM119A up until the third quarter of 2021, and some radio adapter manufacturers are still using it. At LTB, (last time buy) I purchased 11,000 CM119A’s directly from C-Media through the authorized US distributor. I still have a few thousand left - but I’ll run out some day. Hopefully - someone will address all of these issues and be able to fully command the CM119B or something else that’s even better. The B chip has the ABILITY to work as well as any other chipset - it just doesn’t have all of the support necessary to do it right now - at least not in ASL.
Hope this helps…
Kevin W3KKC