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

Joshua Mesilane <josh@...>
 

Hi All,

I LOVE what this radio stands for. I love the fact that it will be an open source radio, but is the hardware going to be open as well? PCB design, chip code, etc? Is the project going to be completely open source & open hardware, or only partially?

As for APRS. Here in VK we primarily use the 2m network with a nation-wide frequency of 145.175 and to a much lesser degree 70cm is used typically for experimental purposes. I run a 2m IGate at home using javAPRSSrvr and the idea of having this run on the device directly I think is exciting, however:

Will the radio be designed in such a way that if we wish to contribute to the project a "2m" version could be designed?
Are the RF components modular and would they allow for swapping? (So that third parties could easily design and produce open hardware alternative RF boards)
Is there any hope for an RS-232 port?

USB-Serial/USB devices in general are notoriously bad for crashing and rebooting in RF environments which can easily cause the serial port to lock up and you then need to remove and re-plug the serial port. I'm not so sure that I'd want to use my NMEA GPS via a USB/Serial adaptor (Or even an FTDI USB GPS) if it were going to be hard wired into a mobile installation. In that environment (IMO and in the field experience) RS232 is the only way to go. In some applications (Remote telemetry systems - And we're not just talking about HAM radio now) quite a lot of gear still uses RS232. I can see a MUCH wider use for this radio if the cost can be kept low, if it has interchangeable/configurable RF stage an RS232 capability. You could even aim for certification of the RF boards to comply with govt standards and market the product as an "open" alternative to the proprietary telemetry/data radios currently on the market.

Cheers,
Josh


On Wed, May 23, 2012 at 5:37 AM, richark <richark@...> wrote:
 

I don't think there is a 'universal' APRS channel for 70cm, like 144.39 is for 2m. Here in the Northwest, we use 440.800 for 9k6 APRS.

Not sure how official this list is, but it provides other alternatives around the world.

http://info.aprs.net/index.php?title=Frequencies

73,
Kenny, KU7M


--- In UniversalDigitalRadio@..., Sander Pool wrote:
>
>
> I will tune my igate to 445.925 and see what I pick up over the next few
> days. Near as I can tell all local (CT/NY area) users are on 144.390 but
> maybe I'm missing out on a lot of traffic. I will also run my mobiles on
> that frequency to see if any other igates are listening. I don't think
> igates announce their frequency but if non-144.390 is common in the US
> it should probably be included so you can see on aprs.fi and other servers.
>
> 73,
>
> Sander W1SOP
>
> On 5/22/2012 2:01 PM, Perry Chamberlain wrote:
> > The 440 aprs packet frequency used is 445.925. In some areas, its dead
> > quiet, in some its packed.
> > But there are 440 freqs to use aprs. It just means you have better
> > propagation, no collisions and as long as your igated, it goes to the
> > WEB apr IS.
>




Re: Codec2

Matthew Pitts <daywalker_blade_2004@...>
 

David,

Not intentionally, by any means; I was discussing a way to link Codec2 and D-Star with Tony VK3JED and Kristoff ON1ARF last fall or winter. I recently thought of finding a way to do this with open-source Echolink clients and D-Star, but haven't had time to experiment with it (working 56 hours a week tends to do things like that). Maybe you and I can work together instead of duplicating each other's efforts.

Matthew Pitts
N8OHU

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

On Tue, May 22, 2012 7:40 PM EDT David Lake (dlake) wrote:

OK now you're talking politics.



I do have a bridge running between D-Star and Echolink, but there are some admin areas that need to be fixed especially around identification.



The audio quality is actually surprisingly good (unless the incoming Echolink is from a repeater that has not filtered it's CTCSS tone out sufficiently in which case it is HORRIBLE).



It's not a production� system purely for me to play with.



David



From: UniversalDigitalRadio@... [mailto:UniversalDigitalRadio@...] On Behalf Of Matthew Pitts
Sent: Tuesday, May 22, 2012 5:31 PM
To: UniversalDigitalRadio@...
Subject: Re: [UniversalDigitalRadio] Re: Codec2








Not directly, no. It is possible to communicate between them with software acting as a bridge between the two, though I haven't actually written the application that will do so. I am also thinking of allowing for normal voice; the D-Star Protocol does include a bridge that allows analogue voice and callsign routing, but this hasn't been implemented by Icom, nor has Jonathan done so, to my knowledge.



Matthew Pitts

N8OHU

Re: No 2m but still an APRS igate?

"John" <john@...>
 

Hi Josh,


--- In UniversalDigitalRadio@..., Joshua Mesilane wrote:
>
> Hi All,
>
> I LOVE what this radio stands for. I love the fact that it will be an open
> source radio, but is the hardware going to be open as well? PCB design,
> chip code, etc? Is the project going to be completely open source & open
> hardware, or only partially?

This is a commercial product.  NorthWest Digital Radio has and is making significant investment to bring it to the marketplace.  The company's goal is to provide an open platform for amateur radio at an attractive price point.

The reality is that every modern piece of equipment has some proprietary intellectual property, and when someone manufacturers a product there is always a trade-off between cost and delivery.  It is often less expensive to buy parts than to make them, and when you buy parts you have to live within the terms of the purchase/license.  For example, to support many Digital Voice protocols you must use a proprietary Vocoder (this isn't just a D-STAR requirement, it applies to all current major Digital Voice protocols).  NWDR will offer a daughter card with a chip that does that, but can't reverse engineer and provide open source for intellectual property they do not own.

Sometimes you have to sign  restrictive agreements just to buy parts from some manufacturers.  This will be a barrier to sharing some low level details.

>
> Will the radio be designed in such a way that if we wish to contribute to
> the project a "2m" version could be designed?
> Are the RF components modular and would they allow for swapping? (So that
> third parties could easily design and produce open hardware alternative RF
> boards)

I won't comment on specific product plans (there are identified product concepts which will be worked on after the initial UDR is ready), but if this product sells well, that will motivate and help fund future products.  The basic design is such that the engineering to place the UDR is pretty straight forward for a few VHF/UHF bands.
 
> Is there any hope for an RS-232 port?

The design for the UDR56K4 is 1 Ethernet and 4 USB ports. 

>
> USB-Serial/USB devices in general are notoriously bad for crashing and
> rebooting in RF environments which can easily cause the serial port to lock
> up and you then need to remove and re-plug the serial port.

I have experienced this in other projects.  This is usually due to ingress via RF on cables.  Using good shielding, quality cables with ferrite chokes on both ends, and good grounding will often mitigate the problem.

> I'm not so sure
> that I'd want to use my NMEA GPS via a USB/Serial adaptor (Or even an FTDI
> USB GPS) if it were going to be hard wired into a mobile installation. In
> that environment (IMO and in the field experience) RS232 is the only way to
> go. 

Cables can be minimized or eliminated using certain form factors for the device,  another option is Bluetooth. (E.g. a bluetooth GPS or Audio device with a micro-adapter (no cable).

73 - John 

Re: Codec2

"John" <john@...>
 

If Codec-2 is ported to the UDR56K a user would have the option of using AMBE based DV (with the add-on card) and/or Codec-2.   Codec-2 has been making a lot of progress but isn't quite ready.  A framing and error-correction protocol is likely required and the current code uses floating point calculations which makes real time coding on difficult on this class of processor.  A move to fixed point and/or the use of a dedicated processor (like what is done with AMBE) should make it feasible.

The UDR56K AMBE card will likely carry the newer chip which supports more coding formats than what is needed for D-STAR, while remaining compatible with D-STAR.  Other AMBE based DV may be possible.


--- In UniversalDigitalRadio@..., Perry Chamberlain <canoeman@...> wrote:
>
> Although this is something that should have been done ten years ago, and is cool amateur radio engineering, the hundreds, and hundreds of thousands of dollars that has been spent on the AMBE CODEC EMBEDED equipment, is a massive barrier to this ever changing the Dstar system. And why yaesu, has decided to come out with yet another digital mode, is baffling.
> ( just a note, I own 6 yeasu radios, so I am a yaesu fan)
> But, thats what amateur radio is all about. But it would be nice if we could choose a common codec.
> I'm financially entrenched in Icom D-star now, so I'm locked in.
>
>
>
> Respectfully
>
> Perry Chamberlain
>
>
> On May 22, 2012, at 9:17 AM, "nikropht" nikropht@... wrote:
>
> > I wanted to let this group know about the progress on Codec2. Codec2 is a fully open source DV codec being developed as a replacement for AMBE2000 see http://www.codec2.org/ for details.
> >
> > -Mike
> > KD5QLN
> >
> >
>

Re: Codec2

"dnolder@..." <vk7yxx@...>
 

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

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.

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.

The Icom/Yaesu situation is a classic. Can you imagine a CW/AM/SSB/FM transceiver that would only work with another transceiver of the same brand? That's effectively what we're talking about.

I really think hardware is the key. An extensible, fully open, software defined, HT, mobile and base with enough processing power on-board to handle whatever is required, even if it has to have an AMBE chip sitting to the side for backwards compatibility. Give the developers the platform and let them have at it.

Icom is the incumbent with the monopoly. Yeasu has played the FUD card with their "Digital Vision" document and the subsequent presentation of their solution at Dayton. We'll be the ones that pay if we play the game.

--- In UniversalDigitalRadio@..., Perry Chamberlain <canoeman@...> wrote:

Although this is something that should have been done ten years ago, and is cool amateur radio engineering, the hundreds, and hundreds of thousands of dollars that has been spent on the AMBE CODEC EMBEDED equipment, is a massive barrier to this ever changing the Dstar system. And why yaesu, has decided to come out with yet another digital mode, is baffling.
( just a note, I own 6 yeasu radios, so I am a yaesu fan)
But, thats what amateur radio is all about. But it would be nice if we could choose a common codec.
I'm financially entrenched in Icom D-star now, so I'm locked in.



Respectfully

Perry Chamberlain

Re: New file uploaded to UniversalDigitalRadio

"John" <john@...>
 

Hi Karen,

The UDR56K has been designed for high duty cycle at 25 watts, but not all tests for specifications have been performed. More data will be available in the future. If you look at the illustration, it has a substantial heat sink to dissipate heat. (Thermal calculations have been done -- testing remains.)

This is not a SDR radio, the de/modulation is performed within a high integration RF IC.

Electronic RX/TX switching very low settle time on frequency change or TX/RX switch. (Fast enough for frequency hopping.)

This is not a kit, it is a complete radio.

More specific specifications will be released in the future, including spectrum plots and other engineering measurements.

The buss from the computing board to transceiver mates the two eurocard boards.

Probably not at Friedrichafen this year -- our team will likely be "heads down" completing integration work through the summer to get the radio ready for the Q4 delivery goal.

--- In UniversalDigitalRadio@..., "Karen Tadevosyan, RA3APW" <ra3apw@...> wrote:

Hi John,

well, UDR56K - sounds good and promising.

Can I have few questions:

- RF TX power 25W is for 100% TX cycle? No degradation or switching to low RF power level?
- any additional cooling systems for 25W RF power and 100% cycle?
- what is RX/TX time (TX delay)? Electronic or mechanical RX/TX switching?
- RX: conventional or SDR (I/Q)?
- bandwidth of I/F filters for different speed (switching filters)? Type of filters?
- two points modulation (VCO + VC-TCXO)?
- RX multisignal selectivity?
- direct interface to TRX?
- availability of description of internal interfaces?
- kit availability?
- do you plan to demonstrate any concept of UDR56K in Friedrichafen, Germany in June 22-24?

Good luck with the UDR56K project!

Karen, RA3APW

Re: No 2m but still an APRS igate?

Joshua Mesilane <josh@...>
 

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.

The reality is that every modern piece of equipment has some proprietary intellectual property, and when someone manufacturers a product there is always a trade-off between cost and delivery.  It is often less expensive to buy parts than to make them, and when you buy parts you have to live within the terms of the purchase/license.  For example, to support many Digital Voice protocols you must use a proprietary Vocoder (this isn't just a D-STAR requirement, it applies to all current major Digital Voice protocols).  NWDR will offer a daughter card with a chip that does that, but can't reverse engineer and provide open source for intellectual property they do not own.

Sometimes you have to sign  restrictive agreements just to buy parts from some manufacturers.  This will be a barrier to sharing some low level details.

Competely understand. I deploy and manage servers that exist predominantly in an open-source environment, however I know that some aspects of the various systems employed do need to interconnect with other proprietary systems which often also means proprietary licensing. I guess the open source and open hardware was more targeted at the design, build etc of the device as much as you can without breaching any existing proprietary licensing arrangements.

If however this is going to be a truly 100% proprietary hardware build (where none or little of the hardware design details are released), then that does take some of the excitement out of the product for me. That's not to say that the product is not without merit (And also not that I won't buy one) but the concept of an open-hardware platform (or even semi-open) as well as software to suit one's needs I think is really exciting. If this is only an open software platform then it does take a little of the excitement out of it. To me, that's kind of like saying "Here, we have this fantastic new radio bolted to a Linux PC - you're allowed to design software to run on the PC, but you're locked in to our API to the radio, and you're not allowed to play with the physical hardware". I know that my description is greatly simplified but isn't playing with hardware what HAMs do? Isn't it what we've been doing for years? Why should the open-ness stop at the software? I will re-iterate however that does not mean that I don't like the product, and also does not mean that i wouldn't buy one.
 

I won't comment on specific product plans (there are identified product concepts which will be worked on after the initial UDR is ready), but if this product sells well, that will motivate and help fund future products.  The basic design is such that the engineering to place the UDR is pretty straight forward for a few VHF/UHF bands.

So essentially at this stage, no. The RF side of the unit will be proprietary and closed, and we're locked in to when expansions are released by/for UDR however you may be suggesting that you're not entirely locking yourself in to 70cm, and that we should watch this space.
 
 
> Is there any hope for an RS-232 port?

The design for the UDR56K4 is 1 Ethernet and 4 USB ports. 

So that's an outright no?
 

I have experienced this in other projects.  This is usually due to ingress via RF on cables.  Using good shielding, quality cables with ferrite chokes on both ends, and good grounding will often mitigate the problem.

But this isn't also entirely unique to RF on cables. Things like Ignition spikes on the DC from the power supply in a car are inevitable and can be for the most part mitigated but do still exist. One can try to mitigate the noise/RF as much as possible however it's going to be a inevitability. I really think that not adding an RS-232 port is somewhat limiting the potential marker for the product. You really do have a wide market outside of HAM radio (and potentially a much wider market than HAM operators) if you can get your RF board certified, but the addition of an RS-232 port would be a requirement.
 


Cables can be minimized or eliminated using certain form factors for the device,  another option is Bluetooth. (E.g. a bluetooth GPS or Audio device with a micro-adapter (no cable).

I think you may have misunderstood what i was suggesting. It was more in relation to USB being unstable in mobile environments and resetting. Something that happens on USB and even moreso on bluetooth (even in stable environments). What I'm perhaps suggesting is that in a mobile environment what happenes if your aprs daemon loses connectivity to the gps? Will your daemon just hang or will it close and re-open the serial port. What happens if the USB device resets and creates a new serial port on the machine? I know these are more software issues, but they all essentially come down to the absense of a serial port.

Perhaps I'm harping on about RS232, but the thing is it's a reliable proven technology, and with so many HAMs out there already having RS232 gear, I think it's a HUGE omission. Particular considering that so many Auto Tuners, TNCs, and even other radios that you might interface with this radio often have inbuilt RS232 (Or TTL, which can be boosted with a MAX232) and to then have to rely on an unknown quantity - an USB - Serial adaptor (FWIW - I had a good quality known USB Serial adaptor blow up and take the Level converter in my TNC for my IGate about three weeks ago, so it DOES happen) when the addition of a RS232 port on the device would seem to make the device more flexible, and marketable.

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

--
VK3XJM
0416039082
josh@...
http://www.zindello.com.au/

Re: Codec2

Perry Chamberlain <canoeman@...>
 

Excellent, you have to love the ingenuity of hams crowd sourcing. I was under the impression the two were not compatible. Great to know this can be overcome.

Ke6anm

Respectfully

Perry Chamberlain


On May 22, 2012, at 4:37 PM, "David Lake (dlake)" <dlake@...> 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.

 

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.

 

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.

 

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. 

 

David

 

From: UniversalDigitalRadio@... [mailto:UniversalDigitalRadio@...] On Behalf Of Perry Chamberlain
Sent: Tuesday, May 22, 2012 5:16 PM
To: UniversalDigitalRadio@...
Subject: Re: [UniversalDigitalRadio] Codec2

 




Although this is something that should have been done ten years ago, and is cool amateur radio engineering, the hundreds, and hundreds  of thousands of dollars that has been spent on the AMBE CODEC EMBEDED equipment, is a massive barrier to this ever changing  the Dstar system. And why yaesu, has decided to come out with yet another digital mode, is baffling.

( just a note, I own 6 yeasu radios, so I am a yaesu fan)

But, thats what amateur radio is all about. But it would be nice if we could choose a common codec.

I'm financially entrenched in Icom  D-star now, so I'm locked in.

 

 

Respectfully

 

Perry Chamberlain

 


On May 22, 2012, at 9:17 AM, "nikropht" <nikropht@...> wrote:

 

I wanted to let this group know about the progress on Codec2. Codec2 is a fully open source DV codec being developed as a replacement for AMBE2000 see http://www.codec2.org/ for details.

-Mike
KD5QLN




Modifying the Design

"John D. Hays" <john@...>
 

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 
  



On Tue, May 22, 2012 at 7:05 PM, Joshua Mesilane <josh@...> 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

Joshua Mesilane <josh@...>
 

Hi John,

Thanks for taking what I said on board, I was worried I may have been a little aggressive and offended you/your team. People don't really like it when you pick on their products saying "what if this" or "what if that" so it's good to see that my feedback hasn't been taken the wrong way.

Once the unit is ready to release to public I'm sure we'll discuss more. I'll be one of those people that falls into the "unsupported mods" category so perhaps there is an opportunity for future development there. I do hope in the future though that the hardware can be opened up for development and experimentation by the community with the support of the parent company.

Completely understand minimum viable product, and I think you should be commended on even getting this far. So often really good products get stumped before they make it to market.

Do you have a delivery expectation for Australia as yet?

Cheers,
Josh



On Wed, May 23, 2012 at 12:43 PM, John D. Hays <john@...> wrote:
 

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 
  



On Tue, May 22, 2012 at 7:05 PM, Joshua Mesilane <josh@...> 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: Codec2

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

"What concerns me more is the (political) resistance to allowing
interoperability/gateways between systems."

Now....

Article 1.56 of the ITU Radio Regulations define amateur service as "A
Radiocommunication service for the purpose of self-training,
intercommunications and technical investigations carried out by
amateurs, that is by duly authorized persons interested in radio
technique solely with a personal aim and without pecuniary interest."

That sounds pretty clear to me. Intercommunication, technical
investigations, no pecuniary interest.

BTW, you have not mentioned Motorola. So far, they are the worst
offender and they have bite. Icom are trying to be open and so far,
things have gone pretty well with them (especially Icom US). It's early
days for Yaesu.

Hardware is only half the battle - software and protocols are needed to
interconnect the hardware. Both parts are important, and that is what I
hope this group manages to achieve.

David

-----Original Message-----
From: UniversalDigitalRadio@...
[mailto:UniversalDigitalRadio@...] On Behalf Of
dnolder@...m
Sent: Tuesday, May 22, 2012 7:52 PM
To: UniversalDigitalRadio@...
Subject: [UniversalDigitalRadio] Re: Codec2

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

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.

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.

The Icom/Yaesu situation is a classic. Can you imagine a CW/AM/SSB/FM
transceiver that would only work with another transceiver of the same
brand? That's effectively what we're talking about.

I really think hardware is the key. An extensible, fully open, software
defined, HT, mobile and base with enough processing power on-board to
handle whatever is required, even if it has to have an AMBE chip sitting
to the side for backwards compatibility. Give the developers the
platform and let them have at it.

Icom is the incumbent with the monopoly. Yeasu has played the FUD card
with their "Digital Vision" document and the subsequent presentation of
their solution at Dayton. We'll be the ones that pay if we play the
game.

--- In UniversalDigitalRadio@..., Perry Chamberlain
<canoeman@...> wrote:

Although this is something that should have been done ten years ago,
and is cool amateur radio engineering, the hundreds, and hundreds of
thousands of dollars that has been spent on the AMBE CODEC EMBEDED
equipment, is a massive barrier to this ever changing the Dstar system.
And why yaesu, has decided to come out with yet another digital mode, is
baffling.
( just a note, I own 6 yeasu radios, so I am a yaesu fan) But, thats
what amateur radio is all about. But it would be nice if we could
choose a common codec.
I'm financially entrenched in Icom D-star now, so I'm locked in.



Respectfully

Perry Chamberlain

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

Yahoo! Groups Links

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: Heard on the street

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

At 03:55 AM 5/23/2012, you wrote:


Not just as a development environment; The stability of Linux makes it ideal for consumer grade products as well, which is why so many consumer grade products (like phones and TVs and routers and firewalls and... etc) use it.
Unless you're in the know, you'd be surprised where Linux pops up. It's a solid workhorse platform, which is extremely versatile.

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

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

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