Rasberry, URI and Bridgecom

Looking at obtaining a Rasberry Pi4, interface it with a URI to be connected to a Bridgecom 222 repeater (BCR-220)

Bridgecom has a cable, BCR to URI(MV-1). What is a MV-1? Will it work with something like the URIxB ?

Has anyone interface a RPi4 thru a URI to a Bridgecomm?

I have two installs ASL to BCR220 running on mini-pc’s.

there is no official release that runs on RPI4 - the official one runs on Stretch, not Buster.
there are too many audio gaps and break-ups on the current release of ASL/RPI (IMHO) so I am not using it on RPI but rather a mini-PC.

I made my own cables - it’s pretty straightforward. However, cable that Bridgecom sells seems pretty clear that it connects to “URI USB Audio interface by DMK Engineering”. But even Google cannot figure out what MV-1 is…

The current product sold by DMK is called URIx and has some issues. Do not buy or plan to use the EEPROM feature. DMK uses the same memory area for some configuration info and when Asterisk writes the settings to EEPROM it scrambles the internal memory of the URIx making it appear to have failed. Also, the output level of the -x version is lower than the original too. (There are alternatives to DMK such as the Repeater-Builder RIM and RIM-lite - the second one needs a different cable with a DB9 plug),

NOTE: The BridgeCom aux interface has no CTCSS generation or detection: you have to use the USBradio channel to get that. (HamVOIP has an RPI4-compatible version but it seems they do not support the USBradio channel yet).

Ken

FYI, DMK Engineerimg sells the URIxB and has corrected the level problem by changing the value of resistors. This was several months ago. All is good now audio levels all good now. Not really a need for eeprom.

73

Marshall - ke6pcv

···

Sent from my iPhone

On Apr 11, 2020, at 6:43 AM, Ken Jamrogowicz via AllStarLink Discussion Groups noreply@community.allstarlink.org wrote:


Ken_Jamrogowicz

    April 11

I have two installs ASL to BCR220 running on mini-pc’s.

there is no official release that runs on RPI4 - the official one runs on Stretch, not Buster.
there are too many audio gaps and break-ups on the current release of ASL/RPI (IMHO) so I am not using it on RPI but rather a mini-PC.

I made my own cables - it’s pretty straightforward. However, cable that Bridgecom sells seems pretty clear that it connects to “URI USB Audio interface by DMK Engineering”. But even Google cannot figure out what MV-1 is…

The current product sold by DMK is called URIx and has some issues. Do not buy or plan to use the EEPROM feature. DMK uses the same memory area for some configuration info and when Asterisk writes the settings to EEPROM it scrambles the internal memory of the URIx making it appear to have failed. Also, the output level of the -x version is lower than the original too. (There are alternatives to DMK such as the Repeater-Builder RIM and RIM-lite - the second one needs a different cable with a DB9 plug),

NOTE: The BridgeCom aux interface has no CTCSS generation or detection: you have to use the USBradio channel to get that. (HamVOIP has an RPI4-compatible version but it seems they do not support the USBradio channel yet).

Ken


Visit Topic or reply to this email to respond.


Previous Replies


J_D

    April 11

Looking at obtaining a Rasberry Pi4, interface it with a URI to be connected to a Bridgecom 222 repeater (BCR-220)

Bridgecom has a cable, BCR to URI(MV-1). What is a MV-1? Will it work with something like the URIxB ?

Has anyone interface a RPi4 thru a URI to a Bridgecomm?


Visit Topic or reply to this email to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, click here.

I was talking about the output. The output side is lower due to the new chip spec. Resistors can’t fix that. It can be fixed by using the follower amp, if you need it.

Allstar docs explain the usefulness of the eeprom, but according to DMK it’s verboten. Of course, they will still sell you one…

The CM119B based radio interfaces are severely hindered (IMHO) because of several reasons. I have a complete evaluation that I’ll share below. And Yes - the EEPROM is necessary to set the flags properly for “amount of” boost and to disable the damn pop filter. 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 CM119B and it fails to operate correctly and will need sent back to the manufacturer to be reprogrammed. Some manufacturers don’t include a EEPROM on their CM119B radio interfaces, and who knows how they get initialized when you plug and replug the radio interface to/from the host. My testings shows these settings get “programmed” randomly when no EEPROM exists and is why ASL recommended that DMK include a EEPROM with every URIxB that’s sold. Masters Communications and Repeater Builder’s radio interfaces only use a genuine crystal controlled CM119A, and they work like they should.

Kevin W3KKC

OK - so you need the EEPROM- just don’t tell ASL that you have one. Does that mean that if you buy a DMK URI without the EEPROM you will have a problem? I did pay for the EEPROM in the last one I bought and, because no one told me not to do it, I let ASL write to it and then had to send it back to DMK for a brain-clean. That info really should be on their web page - sheesh.

The CM119B currently 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 EOL 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 (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.

Besides the RX and TX audio level issues, there are two other big differences. One is the lack of 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, 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 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 doesn’t work as a direct replacement of their prior units. The audio output is 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
http://www.masterscommunications.com/temp/CM119B/

So - we have 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.
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).

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 that the optional EEPROM be made standard so this feature could be commanded off, and that setting reliably retained as the adapter was plugged and unplugged from its host.

In digital systems like VARA FM, the roll-off of the lower frequencies makes it harder to properly detect data because of waveform distortion. This distortion comes from rounding of the digital waveform due to the undesired 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 adapter. This is likely a channel driver issue with AllStar, and might not happen with other applications. 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 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 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, so who knows how these functions get initialized when connecting their adapters to the host computer. It was found that these settings were set randomly if the EEPROM was not present and the radio adapter was plugged and unplugged from its host. Of course, the USB matching resistors on the CM119B should be changed to 39 ohms (from 22 ohms on prior chipsets) but no one is doing that. 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. Aren’t they reading the documentation? Oh wait, some of it is conflicting and outright misleading. C-Media would lead you to believe the CM119B is a direct “drop in” replacement for the CM119A. What about the additional decoupling capacitors on the pins that used to go to the crystal? The original 20pF caps there aren’t going to any good.

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 fixes 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 is greatly reduced as compared to a CM108 or CM119A chipset. Maybe they’re using an adapter that has “pop” filter turned on by accident?

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. Some people still say you don’t need an EEPROM with your CM119B. 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. I do have all of the documentation on the CM119B and I’m willing to share it with responsible people.

Needless to say, IMHO the CM119B is currently a train wreck. Thankfully, C-Media is still producing the CM119A and responsible radio adapter manufacturers are still using it. Newer and cheaper isn’t always better. The CM119A costs about 25 cents more than a CM119B, and while you need a crystal too, it’s still a better value then going through all of this with a CM119B based radio adapter.

Hope this helps…
Kevin W3KKC

An abbreviated version of this story should have been posted in a prominent place (a headline even) on the ASL community web, say, 12 months ago. But at least it’s out there now …

cheers,
Ken

Quite frankly, I’ll likely get some flack for posting this, and while I agree that the story should have been told many months ago, it’s wasn’t my responsibility to report on the shortcomings of any product. It’s only because there are folks like yourself that understand there are other underlying issues, that it gets told. People will cite that I have a conflict of interest because I build and sell radio adapters too, but that doesn’t discount the fact that what I wrote is the truth.

Ken, looking at getting a BCR440 repeater for a local club and trying to come up with a reasonably “easy” plug and play solution for AllStar. I saw your note on the CTCSS generation/detection. how are you doing this on your architecture, through USBradio? Saw a note that it is not recommended on hamvoip. Curious how reliable it is or if this got fixed by BridgeCom? Any other recommendations for BridgeCom solution or another repeater and AllStar interface? Looks like the URIxB side is fixed per KE6PCV bur looks like a CTCSS workaround is still needed. Suggestions?

This is old news I guess. I found an application note in the BridgeCom site that shows how to program the “SYS-OP” slot.

Using this technique the external controller does not need to know anything about CTCSS - it’s handled by the repeater itself. I use this at two sites and it works fine.

Ken