Date   
Re: No 2m but still an APRS igate?

"Tony Langdon, VK3JED" <vk3jed@...>
 

At 04:29 AM 5/23/2012, you wrote:

Here's the good news though. Â If you have a
current igate on 2m, you can replace the
computer with a UDR56K, attach a USB-to-Serial
cable  to the TNC and radio to continue to
service the 144.39 net, while offering 9600 baud
or better APRS on the UDR56K's 70cm radio. Â
Then you would have a dual band igate with less
power requirement (by loosing the computer) and
a much smaller package. Â Attach a diplexer and
dual band antenna and you are ready to go.
Now this is a neat idea!

73 de VK3JED / VK3IRL
http://vkradio.com

Re: Codec2

"Tony Langdon, VK3JED" <vk3jed@...>
 

At 09:37 AM 5/23/2012, you wrote:


CODEC 2 is currently missing any FEC, and will
not operate down at the required bit-rate to be
usable in D-Star. It’s getting there, but I
think it has a way to go so don’t expect a swap-out any time soon.
In time, I'm sure Codec2 will get there.


Now, the Yaesu offer (currently) is a dPMR-based
FDMA system.  But it does look like they will
be going to a DMR TDMA system in the future.
I'm not sold on TDMA myself. That comes from
living in a land known for its wide open spaces,
and a past history of working VHF/UHF
openings. What are the timing (and effective range limitations) of DMR TDMA?


dPMR and DMR both use AMBE2+ - not compatible
directly with AMBE2 in D-Star, but DVSI have
(very cheap) chips that can do both modes. And
of course you can transcode between them, either
in software if someone is willing to pay DVSI
$,000s for the SDK, or in hardware if $20 is more in your budget.

So, what we need (as I proposed at Dayton) is an Open Amateur Trunking protocol that can
transport all these different codecs, and then
allow people to transcode between them.
Agree totally. It would be nice to be able to
say "I want to communicate with..." and let the
network figure out what network and mode that
destination is on, and how the two should be
connected (callsign route? link? via a
reflector or transcoding conference server?).


Yes, you will be locked into D-Star for a while,
but I don’t see why that should be a barrier
to talking to someone on, say, a DMR-based system.Â
From my experience with EchoIRLP, if you find a
way to make the different systems accessible to end users in a single place, in a convenient way, they'll love you for it. :)

The "internetworking protocol" (not to be
confused with IP ;) ) should be open, flexible
and extensible. Almost the subject of a group in its own right! :)

73 de VK3JED / VK3IRL
http://vkradio.com

Re: Codec2

"Tony Langdon, VK3JED" <vk3jed@...>
 

At 11:51 AM 5/23/2012, you wrote:
"this is something that should have been done ten years ago"

QFT

Unfortunately it wasn't, and that the biggest issue I have with the development of D-Star. Having said that, Amateur Radio is already a splintered hobby with many niches, so it's nothing new.
D-STAR was developed a long time ago, technology has moved on since, also.


What concerns me more is the (political) resistance to allowing interoperability/gateways between systems. The transcoding, gateways and transports themselves are all relatively minor feats in comparison. All it takes is "someone" saying they won't allow gating from IRLP to Echolink, Echolink to D-Star, or P25 to whatever, and a segment becomes isolated. We're our own worst enemy and we'll pay for it in real dollars.
Agree totally. To me, the ultimate aim is to have a


I don't want to have to take three HT with me when I leave the house, or have a rack of three mobile rigs in the car. I also don't want my investment in D-Star to become worthless.
I had the same issue back in 2002, when I was running IRLP and Echolink on a single antenna, which meant that two of the 3 ports on my triplexer were taken up with links! As I was the main user, there had to be a better way. I wasn't the only one who thought this, and a few people put their heads together and came up with EchoIRLP, which allowed the same analog endpoint to be used for both networks. With digital, there's no common medium until you get to the end user radio itself, so you either need a multiprotocol radio, or you need infrastructure which can route across networks (and willing network administrators!). At least with digital, it should be possible to transparently carry IDs from end to end, leaving only the need to cross from network to network, and transcoding the audio where necessary.

If the gateways can be built out of something like the UDR, then that could push the protocol conversion as close to the edge of the network as possible, which might scale better, as well as minimising issues of "We don't want XXX on our network!".

73 de VK3JED / VK3IRL
http://vkradio.com

AW: Modifying the Design

"siegfried jackstien" <siegfried.jackstien@...>
 

Now build that for vhf and uhf bands all in one box and we are in business

144, 440 1230 ... and maybe higher?!?

Dg9bfc

Sigi

-----Ursprüngliche Nachricht-----
Von: UniversalDigitalRadio@...
[mailto:UniversalDigitalRadio@...] Im Auftrag von John D. Hays
Gesendet: Mittwoch, 23. Mai 2012 02:43
An: UniversalDigitalRadio@...
Betreff: [UniversalDigitalRadio] Modifying the Design



Josh,

Keeping this short :)

1. The radio side has a very small part count and very high integration.
For the most part, moving to another band has to do with some discrete
components and the PA module. I'm sure some enterprising person will
figure out "unsupported" mods. This radio expects logic level digital in
and out, we aren't taking things to audio level at all, the analog in it
is at the antenna :) The computer side and radio side are separable if
one wanted to really dig into building something to replace the radio.

2. It may be possible to "hack" in a serial interface if a user really
feels the need. But remember there is no need for any external TNC, etc.
except in special circumstances -- one can add them, but the radio does
most functions internally. One of the goals is to keep it an attractive
price, so we try to minimize the extra add-ons that turn it into a
duckbill platypus.

Thanks for your input, enthusiasm, and support. I welcome suggestions and
they will be taken into consideration, however we do have an aggressive
goal and at this point in time, I'm inclined to work toward delivery of
the product we have presented.

One of our principles is to listen to the user community and to be as
responsive and open as possible, with the caveat that some of our team
members still have "day jobs" and other obligations :)

I would rather be open about what we are or can do, than to promise
everything and deliver little of it.


________________________________

John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223
<http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
<http://www.facebook.com/john.d.hays>



On Tue, May 22, 2012 at 7:05 PM, Joshua Mesilane <josh@....au>
wrote:





Hi John,

Thanks for the quick reply.

To avoid this getting too big I'll snip out the bits I'd like to add
further comment/clarification to.



...

Interesting to hear your thoughts. As I said, I do think that this
in a fantastic product, and keep in mind this is only my opinion - nothing
more.

Cheers,
Josh



Re: Modifying the Design

"Howard Small" <howard@...>
 

And still going to be under USD400????

 

Let’s just get this one on the market and then worry about bigger and better (?) models.

 

Howard

VK4BS

 

From: UniversalDigitalRadio@... [mailto:UniversalDigitalRadio@...] On Behalf Of siegfried jackstien
Sent: Wednesday, 23 May 2012 19:14
To: UniversalDigitalRadio@...
Subject: AW: [UniversalDigitalRadio] Modifying the Design

 

 

Now build that for vhf and uhf bands all in one box and we are in business

144, 440 1230 ... and maybe higher?!?

Dg9bfc

Sigi

Re: Codec2

Tim Hardy AF1G <hardyt@...>
 

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.

The most often heard objection to linking FM systems to D-Star seems to be that D-Star users don't want all the white noise from a weak FM station digitized and retransmitted on D-Star, and I agree with this objection. Find a way to limit the retransmission of FM signals onto the D-Star network to only good, mostly full-quieting signals and you will probably overcome these objections.

Echolink and IRLP were a match because they both use the same mode, FM.

Linking one type of digital system to another won't have this specific problem, so I don't see why we couldn't develop this option as long as protocols in each system are satisfied. For example, D-Star sends the callsign of the transmitting station through the network. Make this happen from the non-D-Star system and the D-Star network would probably be satisfied. Otherwise, there will continue to be objections.

Tim, AF1G

---- "Tony Langdon wrote:

=============
At 11:51 AM 5/23/2012, you wrote:
"this is something that should have been done ten years ago"

QFT

Unfortunately it wasn't, and that the biggest issue I have with the
development of D-Star. Having said that, Amateur Radio is already a
splintered hobby with many niches, so it's nothing new.
D-STAR was developed a long time ago, technology has moved on since, also.


What concerns me more is the (political) resistance to allowing
interoperability/gateways between systems. The transcoding, gateways
and transports themselves are all relatively minor feats in
comparison. All it takes is "someone" saying they won't allow gating
from IRLP to Echolink, Echolink to D-Star, or P25 to whatever, and a
segment becomes isolated. We're our own worst enemy and we'll pay
for it in real dollars.
Agree totally. To me, the ultimate aim is to have a


I don't want to have to take three HT with me when I leave the
house, or have a rack of three mobile rigs in the car. I also don't
want my investment in D-Star to become worthless.
I had the same issue back in 2002, when I was running IRLP and
Echolink on a single antenna, which meant that two of the 3 ports on
my triplexer were taken up with links! As I was the main user, there
had to be a better way. I wasn't the only one who thought this, and
a few people put their heads together and came up with EchoIRLP,
which allowed the same analog endpoint to be used for both
networks. With digital, there's no common medium until you get to
the end user radio itself, so you either need a multiprotocol radio,
or you need infrastructure which can route across networks (and
willing network administrators!). At least with digital, it should
be possible to transparently carry IDs from end to end, leaving only
the need to cross from network to network, and transcoding the audio
where necessary.

If the gateways can be built out of something like the UDR, then that
could push the protocol conversion as close to the edge of the
network as possible, which might scale better, as well as minimising
issues of "We don't want XXX on our network!".

73 de VK3JED / VK3IRL
http://vkradio.com

Re: No 2m but still an APRS igate?

Sander Pool <sander_pool@...>
 


I was actually thinking of using a soundmodem to add a second TNC to my D710. The intent was to run Winlink 2000 on one and APRS on the other, from the same laptop. The radio does the -plexing. I could also do the gating between 2m and 70cm APRS in the same way.

Well, that's the theory anyway :)

I've been running igate W1SOP-3 on 445.925 for a while now but haven't received anything but my own test packets from a D72. I think in this area a dedicated 70cm igate is not the best investment of resources yet. Maybe in time.

73,

    Sander W1SOP

On 5/23/2012 5:25 AM, Tony Langdon, VK3JED wrote:
 

At 04:29 AM 5/23/2012, you wrote:

>Here's the good news though. Â If you have a
>current igate on 2m, you can replace the
>computer with a UDR56K, attach a USB-to-Serial
>cable  to the TNC and radio to continue to
>service the 144.39 net, while offering 9600 baud
>or better APRS on the UDR56K's 70cm radio. Â
>Then you would have a dual band igate with less
>power requirement (by loosing the computer) and
>a much smaller package. Â Attach a diplexer and
>dual band antenna and you are ready to go.

Now this is a neat idea!

Re: Codec2

"David Lake (dlake)" <dlake@...>
 

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.

David

Sent from my iPhone

On 23 May 2012, at 04:20, "Tony Langdon, VK3JED" <@vk3jed> wrote:

At 09:37 AM 5/23/2012, you wrote:


CODEC 2 is currently missing any FEC, and will
not operate down at the required bit-rate to be
usable in D-Star. It’s getting there, but I
think it has a way to go so don’t expect a swap-out any time soon.
In time, I'm sure Codec2 will get there.


Now, the Yaesu offer (currently) is a dPMR-based
FDMA system.  But it does look like they will
be going to a DMR TDMA system in the future.
I'm not sold on TDMA myself. That comes from
living in a land known for its wide open spaces,
and a past history of working VHF/UHF
openings. What are the timing (and effective range limitations) of DMR TDMA?


dPMR and DMR both use AMBE2+ - not compatible
directly with AMBE2 in D-Star, but DVSI have
(very cheap) chips that can do both modes. And
of course you can transcode between them, either
in software if someone is willing to pay DVSI
$,000s for the SDK, or in hardware if $20 is more in your budget.

So, what we need (as I proposed at Dayton) is an
Open Amateur Trunking protocol that can
transport all these different codecs, and then
allow people to transcode between them.
Agree totally. It would be nice to be able to
say "I want to communicate with..." and let the
network figure out what network and mode that
destination is on, and how the two should be
connected (callsign route? link? via a
reflector or transcoding conference server?).


Yes, you will be locked into D-Star for a while,
but I don’t see why that should be a barrier
to talking to someone on, say, a DMR-based system.Â
From my experience with EchoIRLP, if you find a
way to make the different systems accessible to
end users in a single place, in a convenient way, they'll love you for it. :)

The "internetworking protocol" (not to be
confused with IP ;) ) should be open, flexible
and extensible. Almost the subject of a group in its own right! :)

73 de VK3JED / VK3IRL
http://vkradio.com



------------------------------------

Yahoo! Groups Links


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:
 

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.

The most often heard objection to linking FM systems to D-Star seems to be that D-Star users don't want all the white noise from a weak FM station digitized and retransmitted on D-Star, and I agree with this objection. Find a way to limit the retransmission of FM signals onto the D-Star network to only good, mostly full-quieting signals and you will probably overcome these objections.

Echolink and IRLP were a match because they both use the same mode, FM.

Linking one type of digital system to another won't have this specific problem, so I don't see why we couldn't develop this option as long as protocols in each system are satisfied. For example, D-Star sends the callsign of the transmitting station through the network. Make this happen from the non-D-Star system and the D-Star network would probably be satisfied. Otherwise, there will continue to be objections.

Tim, AF1G

---- "Tony Langdon wrote:

=============
At 11:51 AM 5/23/2012, you wrote:
>"this is something that should have been done ten years ago"
>
>QFT
>
>Unfortunately it wasn't, and that the biggest issue I have with the
>development of D-Star. Having said that, Amateur Radio is already a
>splintered hobby with many niches, so it's nothing new.

D-STAR was developed a long time ago, technology has moved on since, also.

>What concerns me more is the (political) resistance to allowing
>interoperability/gateways between systems. The transcoding, gateways
>and transports themselves are all relatively minor feats in
>comparison. All it takes is "someone" saying they won't allow gating
>from IRLP to Echolink, Echolink to D-Star, or P25 to whatever, and a
>segment becomes isolated. We're our own worst enemy and we'll pay
>for it in real dollars.

Agree totally. To me, the ultimate aim is to have a

>I don't want to have to take three HT with me when I leave the
>house, or have a rack of three mobile rigs in the car. I also don't
>want my investment in D-Star to become worthless.

I had the same issue back in 2002, when I was running IRLP and
Echolink on a single antenna, which meant that two of the 3 ports on
my triplexer were taken up with links! As I was the main user, there
had to be a better way. I wasn't the only one who thought this, and
a few people put their heads together and came up with EchoIRLP,
which allowed the same analog endpoint to be used for both
networks. With digital, there's no common medium until you get to
the end user radio itself, so you either need a multiprotocol radio,
or you need infrastructure which can route across networks (and
willing network administrators!). At least with digital, it should
be possible to transparently carry IDs from end to end, leaving only
the need to cross from network to network, and transcoding the audio
where necessary.

If the gateways can be built out of something like the UDR, then that
could push the protocol conversion as close to the edge of the
network as possible, which might scale better, as well as minimising
issues of "We don't want XXX on our network!".

73 de VK3JED / VK3IRL
http://vkradio.com

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: Codec2

"Curt, WE7U" <curt.we7u@...>
 

On Wed, 23 May 2012, Tyrell Berry wrote:

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.
Witness, 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: 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.

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: Codec2

"David Lake (dlake)" <dlake@...>
 

Tim

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.

The most often heard objection to linking FM systems to D-Star seems to be that D-Star users don't want all the white noise from a weak FM station digitized and retransmitted on D-Star, and I agree with this objection. Find a way to limit the retransmission of FM signals onto the D-Star network to only good, mostly full-quieting signals and you will probably overcome these objections.

Echolink and IRLP were a match because they both use the same mode, FM.

Linking one type of digital system to another won't have this specific problem, so I don't see why we couldn't develop this option as long as protocols in each system are satisfied. For example, D-Star sends the callsign of the transmitting station through the network. Make this happen from the non-D-Star system and the D-Star network would probably be satisfied. Otherwise, there will continue to be objections.

Tim, AF1G

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.

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:

**


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.

The most often heard objection to linking FM systems to D-Star seems to be
that D-Star users don't want all the white noise from a weak FM station
digitized and retransmitted on D-Star, and I agree with this objection.
Find a way to limit the retransmission of FM signals onto the D-Star
network to only good, mostly full-quieting signals and you will probably
overcome these objections.

Echolink and IRLP were a match because they both use the same mode, FM.

Linking one type of digital system to another won't have this specific
problem, so I don't see why we couldn't develop this option as long as
protocols in each system are satisfied. For example, D-Star sends the
callsign of the transmitting station through the network. Make this happen
from the non-D-Star system and the D-Star network would probably be
satisfied. Otherwise, there will continue to be objections.

Tim, AF1G

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.

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: 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:


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@...
<mailto: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.

The most often heard objection to linking FM systems to D-Star seems
to be that D-Star users don't want all the white noise from a weak
FM station digitized and retransmitted on D-Star, and I agree with
this objection. Find a way to limit the retransmission of FM signals
onto the D-Star network to only good, mostly full-quieting signals
and you will probably overcome these objections.

Echolink and IRLP were a match because they both use the same mode, FM.

Linking one type of digital system to another won't have this
specific problem, so I don't see why we couldn't develop this option
as long as protocols in each system are satisfied. For example,
D-Star sends the callsign of the transmitting station through the
network. Make this happen from the non-D-Star system and the D-Star
network would probably be satisfied. Otherwise, there will continue
to be objections.

Tim, AF1G

---- "Tony Langdon wrote:

=============
At 11:51 AM 5/23/2012, you wrote:
>"this is something that should have been done ten years ago"
>
>QFT
>
>Unfortunately it wasn't, and that the biggest issue I have with the
>development of D-Star. Having said that, Amateur Radio is already a
>splintered hobby with many niches, so it's nothing new.

D-STAR was developed a long time ago, technology has moved on since,
also.

>What concerns me more is the (political) resistance to allowing
>interoperability/gateways between systems. The transcoding, gateways
>and transports themselves are all relatively minor feats in
>comparison. All it takes is "someone" saying they won't allow gating
>from IRLP to Echolink, Echolink to D-Star, or P25 to whatever, and a
>segment becomes isolated. We're our own worst enemy and we'll pay
>for it in real dollars.

Agree totally. To me, the ultimate aim is to have a

>I don't want to have to take three HT with me when I leave the
>house, or have a rack of three mobile rigs in the car. I also don't
>want my investment in D-Star to become worthless.

I had the same issue back in 2002, when I was running IRLP and
Echolink on a single antenna, which meant that two of the 3 ports on
my triplexer were taken up with links! As I was the main user, there
had to be a better way. I wasn't the only one who thought this, and
a few people put their heads together and came up with EchoIRLP,
which allowed the same analog endpoint to be used for both
networks. With digital, there's no common medium until you get to
the end user radio itself, so you either need a multiprotocol radio,
or you need infrastructure which can route across networks (and
willing network administrators!). At least with digital, it should
be possible to transparently carry IDs from end to end, leaving only
the need to cross from network to network, and transcoding the audio
where necessary.

If the gateways can be built out of something like the UDR, then that
could push the protocol conversion as close to the edge of the
network as possible, which might scale better, as well as minimising
issues of "We don't want XXX on our network!".

73 de VK3JED / VK3IRL
http://vkradio.com
&#92;

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:
 

... 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: 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.

The most often heard objection to linking FM systems to D-Star seems to be that D-Star users don't want all the white noise from a weak FM station digitized and retransmitted on D-Star, and I agree with this objection. Find a way to limit the retransmission of FM signals onto the D-Star network to only good, mostly full-quieting signals and you will probably overcome these objections.
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.

Linking one type of digital system to another won't have this specific problem, so I don't see why we couldn't develop this option as long as protocols in each system are satisfied. For example, D-Star sends the callsign of the transmitting station through the network. Make this happen from the non-D-Star system and the D-Star network would probably be satisfied. Otherwise, there will continue to be objections.
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.

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.
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