Re: Codec2
Tyrell Berry <kd7kuj@...>
When dealing with music, I consider myself an audiophile. When I buy a CD, I rip it to my home server in the FLAC format; No, I don't carry loss less audio around on my portable devices... But I like AAC when my player supports it, and MP3 when it doesn't. My primary concern with storing my primary source in either lossy format is that if I convert between the two, it's going to lose MORE data/quality with each conversion... Lossy on top of lossy is bad. The same is true of these vocoders... They are all lossy formats... And at such low band widths, they don't leave much left over to be lost again. My point is this: A transcoder between any two formats that use different vocoders will significantly degrade the audio quality... Maybe it will still be legible, but I doubt it will be a pleasant experience. In light of that, going from one digital mode to another may or may not be considered worse than going from FM to digital, depending on the real world performance of that double (or potentially triple in a poorly optimized network) lossy conversion.
On May 23, 2012 9:32 AM, "Tim Hardy AF1G" <hardyt@...g> wrote:
|
|
Re: Codec2
"Curt, WE7U" <curt.we7u@...>
On Wed, 23 May 2012, Tyrell Berry wrote:
A transcoder between any two formats that use differentWitness, in order of decreasing quality, conversations from: *) Analog phone -> analog phone *) Analog phone -> cell-phone *) cell-phone -> cell-phone, same technology *) cell-phone -> cell-phone, different technology I've had extremely poor conversations with the last mode, with a friend using a different kind of cell-phone technology than my phone. It's _exactly_ what's being discussed here, conversions from once codec to another. The more conversions in the line, the poorer the quality. Real-world examples that most of us experience on at least a weekly basis. -- Curt, WE7U. http://www.eskimo.com/~archer Windows ate my homework!
|
|
Re: Codec2
"David Lake (dlake)" <dlake@...>
Tim
toggle quoted messageShow quoted text
If this was professional radio, then I'd agree. But it isn't - it's hobby radio, and the goal is to experiment, not to provide a service-provider grade network. As a friend of mine recently told a group, if you want high data rates, 100% coverage, 5 9s reliability and black-box equipment, we have 7 main mobile operators and at least two dozen MVNOs that will do that for you. And you can buy their hardware in the supermarket for next-to-nothing ! So I see nothing wrong with linking between modes at any quality in the spirit of "education through experimentation in radio" as my licence says. If you are in a country that uses Amateur radio to support emergency response, I would have thought that linking at any quality was better than no linking at all. I'm not sure of the situation in the US, but across much of the EU, voice transmission is rarely used these days by emergency services for routine matters - most dispatch is done by data with a hard copy printed in the vehicle for audit/accuracy purposes. I know that Italy still has individual analogue radio systems for each force/area but is swapping out later this year for a nationwide TETRA network and is one of the last countries to do so. TETRAPol in France is even older then TETRA - their national network went in some 20 years ago. The UK was late to the game, and it wasn't until about 6 years ago that the last isolated users came off their own radio systems onto the national backbone. I don't see Amateurs building a global TETRA cellular system any time soon..... David Sent from my iPhone
On 23 May 2012, at 10:31, "Tim Hardy AF1G" <hardyt@...> wrote:
I'm not opposed to linking different protocols, but there is value in some of the objections to linking specific networks. If the objections or concerns can be mitigated, then fewer people would resist.
|
|
Re: Codec2
Tim Hardy AF1G <hardyt@...>
A good point! We'll have to see what shakes out as the experimenters "experiment" with linking digital systems.
toggle quoted messageShow quoted text
73 de Tim, AF1G ---- Tyrell Berry <kd7kuj@...> wrote: ============= When dealing with music, I consider myself an audiophile. When I buy a CD, I rip it to my home server in the FLAC format; No, I don't carry loss less audio around on my portable devices... But I like AAC when my player supports it, and MP3 when it doesn't. My primary concern with storing my primary source in either lossy format is that if I convert between the two, it's going to lose MORE data/quality with each conversion... Lossy on top of lossy is bad. The same is true of these vocoders... They are all lossy formats... And at such low band widths, they don't leave much left over to be lost again. My point is this: A transcoder between any two formats that use different vocoders will significantly degrade the audio quality... Maybe it will still be legible, but I doubt it will be a pleasant experience. In light of that, going from one digital mode to another may or may not be considered worse than going from FM to digital, depending on the real world performance of that double (or potentially triple in a poorly optimized network) lossy conversion.
On May 23, 2012 9:32 AM, "Tim Hardy AF1G" <hardyt@...> wrote:
**
|
|
Open Source Hardware...
UniversalDigitalRadio-owner@...
... doesn't exist.
This forum has been wonderfully active on a variety of topics. It's great to see the exchange as hams weigh in with their hopes and dreams, but there is one topic that I need to address; the notion of open source hardware. I worked in Silicon Valley for 30 years, both with and for, a variety of semiconductor companies. I have personally negotiated with both ARM and MIPs and let me tell you, there is no open source hardware. Today's designs use high integration ICs which are designed in HDLs. They often include licensed IP from other sources under highly restrictive agreements. They are the companies most valuable assets and they are not released to anyone in any form. In order for us to use these devices we may enter into Non Disclosure Agreements which state that we will not release any design information to third parties, that means you. In particular if there are errata we cannot share either the problem or the fix. LEGAL DISCLAIMER: I am not saying that any vendors chips that I use now, or have ever used, actually have now or ever have had any errata (hi hi). What we will provide is schematics and assembly diagrams of released product under copyright. In particular, we will document all connector interfaces both external and internal, to aid in experimentation. We will not be posting manufacturing data, such as gerber files, detailed BOMs and mechanical drawings, but if you have an amateur radio project that requires more information; send us an email briefly describing what you'r trying to do and we'll do our best to help you. 73 - Bryan Hoyer
|
|
Re: Open Source Hardware...
"Rick Muething" <rmuething@...>
Brian,
The Winlink development team would be interested in purchasing two units
when available through our 501C3 organization the Amateur Radio safety
Foundation. www.arsfi.org We have a
number sights were these could be tested here in Florida.
I have felt for a long time this is the kind of product that is needed in
amateur radio. It provides an important vehicle to leverage and encourage
advancement in digital communications.
I am also working with the CODEC2 group on the open source CODEC 2 and
modem. This radio should be very possible to support continual voice and
relatively high bandwidth FEC data simultaneously.
Thanks,
Rick Muething, KN6KB
Sent: Wednesday, May 23, 2012 3:02 PM
Subject: [UniversalDigitalRadio] Open Source
Hardware... ... doesn't exist.
|
|
Re: Open Source Hardware...
"William Stillwell - KI4SWY" <wkstill@...>
the comment “ … doesn’t exist” is in accurate.
Ardruino is very open source hardware. (all the way down to the boot loader, and development packages)
Fpga projects can be open source as well.
UDR is not open source hardware, it supports open source software development.
Unlike 99% of all “node adapters” are 100% closed software development.
Yes, no chip manufacture is going to give you there chip secrets, but they sure are going to tell you how you can use it.
From: UniversalDigitalRadio@... [mailto:UniversalDigitalRadio@...] On Behalf Of UniversalDigitalRadio-owner@...
Sent: Wednesday, May 23, 2012 3:02 PM To: UniversalDigitalRadio@... Subject: [UniversalDigitalRadio] Open Source Hardware...
... doesn't exist.
|
|
Re: Codec2
Tom Azlin N4ZPT <tom@...>
I would add that there has been a lot of work done looking at tandeming vocoders. Conclusion a noticeable loss in audio quality measured in the mean opinion score. If you could find a way to bridge between the two vocoders that would avoid the existing patents that would be good. So I will stick with D-STAR where I have the most invested. Maybe cross link co-located FM repeaters in a way to set up headers in a meaningful way.
73, tom n4zpt On 5/23/2012 12:53 PM, Tyrell Berry wrote: \
|
|
Re: Open Source Hardware...
Tyrell Berry <kd7kuj@...>
A few years back, there was an organization that developed two open source phone called the Openmoko Neo and Freerunner. The devices were nearly entirely open source... Everything but the GSM Radio, which they claimed couldn't be avoided due to FCC type approval, which is probably true. But the device in it's entirety, down to engineering drawings of the boards and cad drawings of the case were available for download from openmoko.org. Of course, sacrifices were made... to get around NDAs they had to use fairly archaic chips, even for the time... As such, the device sold very poorly, and I wouldn't advise following in those footsteps, but to say it doesn't exist is a bit rash.
On May 23, 2012 12:31 PM, <UniversalDigitalRadio-owner@...> wrote:
|
|
Re: Codec2
"Tony Langdon, VK3JED" <vk3jed@...>
At 02:47 AM 5/24/2012, you wrote:
So the main benefit of TDMA is being able to double repeater capacity in one RF slot. That's one antenna, one duplexer, one site rental. Certainly in the UK where we pay commercial rates for tower access and there is no free spectrum, it's a big deal.True, useful in densely populated areas. Out where I am, where there's fewer repeaters and bigger distances, I'm concerned about the cost of that increased capacity - namely the effect on range, caused by timing limitations (AKA physics - the speed of light!). 73 de VK3JED / VK3IRL http://vkradio.com
|
|
Re: Codec2
"Tony Langdon, VK3JED" <vk3jed@...>
At 11:02 PM 5/23/2012, you wrote:
I'm not opposed to linking different protocols, but there is value in some of the objections to linking specific networks. If the objections or concerns can be mitigated, then fewer people would resist.Actually, there is a way, but it requires some money thrown at the problem. I have a German built DSP that is incredibly effectively at removing FM background noise. Maybe something to experiment with at some stage. Echolink and IRLP were a match because they both use the same mode, FM.Being digital all round, that shouldn't be too difficult, though it might need some lookup tables for systems which don't use the callsign as a MAC address. I believe TRBO uses a numeric ID, for instance. 73 de VK3JED / VK3IRL http://vkradio.com
|
|
Re: Codec2
"Tony Langdon, VK3JED" <vk3jed@...>
At 02:53 AM 5/24/2012, Tyrell Berry wrote:
The same is true of these vocoders... They are all lossy formats... And at such low band widths, they don't leave much left over to be lost again. My point is this: A transcoder between any two formats that use different vocoders will significantly degrade the audio quality... Maybe it will still be legible, but I doubt it will be a pleasant experience.Another reason to push the network translation to the edge of the network, and another reason why EchoIRLP was better than other cross network solutions at the time. If you have multi protocol capable gateways, they will could attempt to choose a path that limits the number of transcoding operations to the ideal (0 between networks which use the same vocoder - EchoIRLP achieved this, or 1 when there was no vocoder in common). 73 de VK3JED / VK3IRL http://vkradio.com
|
|
Re: Codec2
"Tony Langdon, VK3JED" <vk3jed@...>
At 03:14 AM 5/24/2012, Curt, WE7U wrote:
Witness, in order of decreasing quality, conversations from:Which is a good reason to be clever about how we do things. :) I'm a believer in fiddling with the signal as little as possible, for this very reason. 73 de VK3JED / VK3IRL http://vkradio.com
|
|
Cross linking (Was: Codec2)
"John D. Hays" <john@...>
The argument that analog should never be linked to digital because of white noise and other artifacts forgets that Vocoders (as opposed to Codecs) like AMBE and Codec-2 are specifically looking for speech and work hard to remove background noise. All audio starts and ends as analog and transitioning from an analog FM to digital voice system using a vocoder applies the same filtering to the audio. I think the folks the argument haven't tested their theory. Some who have tested it, can probably show some issues like drop out, overdrive on CTCSS, etc. that will degrade the system, however, well conditioned audio from an analog FM source should encode much like analog voice from a microphone.
The second argument is often that the callsign information isn't there in an analog signal or incompatible digital voice signal. Rules may vary around the world, but here in the US the ID is for the transmitter where the signal originates. It doesn't need to be passed through the network for identification purposes (other than courtesy or vanity) when it comes to the regulations. In D-STAR, the callsign is also used as an address for directed transmissions. In a linked system the only address needed is the one that identifies the repeater(s) and conference channels, so that the traffic is properly routed.
Any linking protocol that mixes systems should contain an ability to identify the type of traffic source (Analog, Digital) and encoding (AMBE, Codec-2, etc.) and allow the administrator of a repeater to determine which traffic to accept.
|
|
Re: Cross linking (Was: Codec2)
"David Lake (dlake)" <dlake@...>
John
Completely agree.
Where I’ve interworked FM to D-Star, I’ve found the results to be perfectly acceptable within the confines of Amateur Radio.
You wouldn’t want to listen to Bartok or One Direction over it, but it works and that’s what matters.
All the time we have the entrenched view of “this is my system and it won’t connect to your system” we risk siloing and isolating users. The net effect is less usage on amateur bands and less amateurs – exactly the effect that is being seen in many countries.
On the callsign ID, that is an interesting point. Rules do vary from country to country, but what I’ve found is that Amateurs naturally ID every few minutes anyway. In the UK, rules were relaxed on D-Star so that no voice ID is required, but you will still typically here an over start with “G6TBA from G4ULF” and end with “from G4ULF.” Old habits die hard, and I certainly ID on every over still.
So, again, like you, I think these are both non-issues.
To me, the benefits in terms of increase usage and more linking possibilities far outweigh these issues.
BTW, EchoIRLP does NOT allow interworking IRLP and Echolink as the IRLP crowd insist on the end-point being a repeater. EchoIRLP allows a repeater to act as an IRLP node and and Echolink node, but it does not bridge the audio together.
David
From: UniversalDigitalRadio@... [mailto:UniversalDigitalRadio@...] On Behalf Of John D. Hays
Sent: Wednesday, May 23, 2012 5:03 PM To: UniversalDigitalRadio@... Subject: [UniversalDigitalRadio] Cross linking (Was: Codec2)
The second argument is often that the callsign information isn't there in an analog signal or incompatible digital voice signal. Rules may vary around the world, but here in the US the ID is for the transmitter where the signal originates. It doesn't need to be passed through the network for identification purposes (other than courtesy or vanity) when it comes to the regulations. In D-STAR, the callsign is also used as an address for directed transmissions. In a linked system the only address needed is the one that identifies the repeater(s) and conference channels, so that the traffic is properly routed.
Any linking protocol that mixes systems should contain an ability to identify the type of traffic source (Analog, Digital) and encoding (AMBE, Codec-2, etc.) and allow the administrator of a repeater to determine which traffic to accept.
Given these two "non-issues", the rest is just politics. :) John D. Hays PO Box 1223, Edmonds, WA 98020-1223
|
|
Re: Cross linking (Was: Codec2)
Matthew Pitts <daywalker_blade_2004@...>
John,
toggle quoted messageShow quoted text
I think as long as the proper display is there, someone using the 1.2k gmsk modem with analog audio (or echolink with callsign pass-through) won't really be noticed. It will probably require some special tricks somewhere along the line to properly work with the Icom gateway software and such, but that's already taken care of in Jomathan's software. Matthew Pitts N8OHU ------------------------------
On Wed, May 23, 2012 7:02 PM EDT John D. Hays wrote:
The argument that analog should never be linked to digital because of white
|
|
Re: Cross linking (Was: Codec2)
"John D. Hays" <john@...>
Matthew,
toggle quoted messageShow quoted text
The truth of the matter is, for linking, it just doesn't matter. Having a proper callsign in the "MY" field only matters in two places: 1. If going through an Icom G2 gateway which looks to see if it has the callsign in the trust server database. (G4ULF can check or not, depending on the administrator's preference.)
2. If using callsign addressing, since the receiver needs it to set the return route. (By copying to the UR address) On linked repeaters DPLUS mostly doesn't look at the MY or the UR except for when issuing link/unlink commands (and echo/info) and a few special cases.
The other major D-STAR linking systems want something that looks like a legitimate callsign in the MY address, and filter's out callsign addressed (the UR is not CQCQCQ...) traffic, which is not intended for the link in the first place.
Understanding this, for the most part as long as the MY field contains a USRoot Trust registered user callsign, transmissions will be passed. For other addressed protocols besides D-STAR, its mainly a hash between callsign and address. Analog would simply need some understood address (for Icom G2 D-STAR routed calls it would have to have a registered callsign in the MY) That's it. From a technical point of view, that is...
On Wed, May 23, 2012 at 6:24 PM, Matthew Pitts <daywalker_blade_2004@...> wrote:
|
|
Re: Cross linking (Was: Codec2)
"David Lake (dlake)" <dlake@...>
The entire “MY” call is unenforceable. It is sent in clear text, is programmed by the user and therefore is suspicious.
By default, my code does not check D-Star MY calls for one simple reason – it could land me in gaol. In most of the EU, it would be illegal for me acting as a citizen to deny another citizen access to systems designed for the whole community based on my perception of their licensed status. If it turned out that the other party WAS licensed and I had denied them access, then I would have committed a very serious offence in both anti-discrimination and Human Rights terms. That is a custodial sentence. The only people with the power to investigate illegal transmissions are the police (or Ofcom working with the police) and the public is advised to stay out of police business. As any form of closed system is also not allowed, that means that irrespective of what someone TELLS me either verbally or by electronic ID, I cannot afford to block them for fear of acting illegally. If they break the rules of their licence, it is not for me to say other than reporting my suspicions to the authorities. So, callsign ID on D-Star is pretty meaningless ! David
|
|
Re: Cross linking (Was: Codec2)
"Tony Langdon, VK3JED" <vk3jed@...>
At 09:02 AM 5/24/2012, you wrote:
Any linking protocol that mixes systems should contain an ability to identify the type of traffic source (Analog, Digital) and encoding (AMBE, Codec-2, etc.) and allow the administrator of a repeater to determine which traffic to accept.A key issue identified many years ago is that control over what sort of traffic should be allowed to pass through a gateway should be in hands of the administrator of that particular gateway/repeater. If I want to allow transmissions of analog origin on my repeater, I should be allowed to simply enable reception of that type of traffic. And if I don't want it (there are legal reasons for not allowing _some_ analog systems to link to digital here), then I should be able to block it. Similarly, I should not be able to "force" unwanted traffic types on another gateway. Given these two "non-issues", the rest is just politics. :)My sentiments exactly. :) 73 de VK3JED / VK3IRL http://vkradio.com
|
|
Re: Cross linking (Was: Codec2)
"Tony Langdon, VK3JED" <vk3jed@...>
At 11:18 AM 5/24/2012, you wrote:
All the time we have the entrenched view ofAt the end of the day, all that the majority of people want to be able to do is talk to their friends around the world, and not have to jump through political hoops to do so. Similar observations in Australia. However, for us, this was always a non-issue, because transmitter ID, not origin ID is the critical factor. This was one of the original design decisions, though strictly speaking, there is a bridge between the two at the protocol level, but it takes place in the EchoIRLP node when running Echolink. A copy of thebridge does act as a local protocol translator between Echolink and IRLP/Speak Freely (some control functions and audio transport layer), so the IRLP software can remain in control of the audio path, as well as provide sensible status reports to both networks as needed. 73 de VK3JED / VK3IRL http://vkradio.com
|
|