Re: API's & Documentation Underway?
"John D. Hays" <john@...>
Hi Brian, We encourage development for this device, hence the high use of FOSS (Free Open Source Software) by NorthWest Digital Radio. Development is pretty straight forward. The device is running a Debian Squeeze distribution, so the baseline is familiarity with development under Linux. In house development is done running a cross compilation tool chain on desktop Debian systems (to take advantage of multi-core processors and high memory), either native or as a VM, and the completed builds are transferred to the CPU board for the radio.
What we will provide are APIs to control the radio; frequency, shift, modulation choice, power, and any other similar controls. We will also provide drivers to send and receive data between the CPU board and radio board, and between the CPU board and the Vocoder board.
On Sun, May 27, 2012 at 5:02 PM, Brian Duck <bkduck@...> wrote:
|
|
API's & Documentation Underway?
"Brian Duck" <bkduck@...>
So, I'm interested in custom application development for the UDR56K-4.
Are there API's under development or documentation to review? Thanks for your efforts on what looks to be a great platform. Brian Duck W1DUC bkduck@gmail.com
|
|
Re: Screen shots
"john_ke5c" <ke5c@...>
In general, I'm very interested in the UDR, I've done a good bit of testing (with Darren, G0HWW) of DTN, NORM, IPv6 and other protocols over 9K6 AX.25, D-Star DD mode, and to me it seems that it may hit a sweet-spot between RF range and data throughput (if there is indeed such a thing). I guess EmComm would be my main use/interest for it.I too have been wondering about 9600 (or thereabouts) data. We might be able to take advantage of the gateway/internet infrastructure if a "Dd" DStar packet could be defined that would use all bits for just data, no voice. I'm guessing (hoping actually), the band modules and gateways would pass those so long as the headers were okay. Of course, it would sound like garbage to DV radios, but you could commit band modules to data only. dplus might burp, but you would probably callsign route such "data" packets anyway. Just brainstorming, 73--john
|
|
Re: Screen shots
"ke7kro" <basil@...>
--- In UniversalDigitalRadio@yahoogroups.com, "c0j" <jpronans@...> wrote:
Hi John, Hope you remember me from our posts on paclink-unix. Thanks for the postfix howto. This project is an out growth of our work with the SheevaPlug and uses paclink-unix & Linux RMS. Look forward to you getting a hold of some of our units for fun & testing. /Basil KE7KRO
|
|
Re: Screen shots
Bryan Hoyer <bhhoyer@...>
Yes we are using Paclink Unix and Linux RMS.
toggle quoted messageShow quoted text
We have had interest from European distributors but will not have them set-up for first delivery. Best regards to your sister, Bryan
On May 26, 2012, at 2:02 PM, c0j wrote:
|
|
Re: Screen shots
"c0j" <jpronans@...>
--- In UniversalDigitalRadio@yahoogroups.com, "k7udr" <bhhoyer@...> wrote:
Hi Bryan, all, Are you using paclink-unix/LinuxRMS or something else? In general, I'm very interested in the UDR, I've done a good bit of testing (with Darren, G0HWW) of DTN, NORM, IPv6 and other protocols over 9K6 AX.25, D-Star DD mode, and to me it seems that it may hit a sweet-spot between RF range and data throughput (if there is indeed such a thing). I guess EmComm would be my main use/interest for it. Will you be shipping to Europe do you think or will my sister in New Jersey be getting a delivery later in the year ;)? Regards John EI7IG
|
|
Re: compatible with DD-WRT?
steve <stevewa206@...>
Hummm.... Connecting the DD-WRT to the Ethernet port would work fine...I'm wondering if you used the Open-WRT with the mesh routing, if then you could mesh all the other UDR56K's on the network? If your just using the UDR56K's as layer 2 ( TCP/IP over AX.25 ) and meshing at the WRT level, that would be pretty cool. So you use the UDR56K's as a long range mesh layer and have the WRT at 2.4 Ghz for local mesh. Hummm...that would be nice because then other hams in the area could be seen.
toggle quoted messageShow quoted text
Then again, you can run the MESH protocol on the UDR56K too, on the unit itself. But if the WRT has it all there, that would be cool. Steve N0FPF
On 5/26/2012 10:04 AM, John D. Hays wrote:
|
|
Re: compatible with DD-WRT?
"John D. Hays" <john@...>
David,
toggle quoted messageShow quoted text
I'm wondering what you are looking for in "compatibility"? The UDR56K certainly should work through a router running DD-WRT or OpenWRT.
One could port DD-WRT to the UDR56K, but to what purpose? In development we are using a full Linux distribution, specifically Debian Squeeze and can run various routing protocols and applications that run on Linux.
On Sat, May 26, 2012 at 7:03 AM, w2lnx <david.bern@...> wrote:
|
|
compatible with DD-WRT?
"w2lnx" <david.bern@...>
Do you have any plans to be compatible with DD-WRT?
Thank you, David, W2LNX
|
|
Re: Screen shots
"k7udr" <bhhoyer@...>
I'll post an app note on using the UDR56K with the Winlink system next week, including screen shots.
toggle quoted messageShow quoted text
Bryan
--- In UniversalDigitalRadio@yahoogroups.com, "kgregc" <kgregc@...> wrote:
|
|
Screen shots
"kgregc" <kgregc@...>
Are there any screen shots of the Universal Radio software?
Greg
|
|
Re: Cross linking (Was: Codec2)
Jonathan Naylor <naylorjs@...>
The specification for the preamble is pretty simple, and I reckon could be implemented easily by an experienced software developer, you'd only need an NCO I reckon. If someone were to implement such a thing then I'd happily add it to my software, but until then.... Jonathan G4KLX
From: John To: UniversalDigitalRadio@... Sent: Thursday, 24 May 2012, 20:50 Subject: [UniversalDigitalRadio] Re: Cross linking (Was: Codec2) The D-STAR specification has a solution to this "non-issue" -- it involves a little MSK preamble on analog transmissions. http://www.d-star.asia/misc/shogen_4_2_8.pdf It seems in it's simplest form, one could use a PIC or Arduino and use UR:CQCQCQ with the MY set to the radio's callsign and put it in the TX audio and PPT lines for a radio, similar to what was done on APRS for voice (in fact add a GPS and send coordinates in a payload as well). For linking, this is all that is really needed. An analog repeater with a decoder would simply tell the linking system that the station whose callsign was in the MY field is present at that analog repeater. It you want directed traffic (callsign addressed), then a way to capture or set the UR callsign would be required.
--- In UniversalDigitalRadio@..., "siegfried jackstien" wrote: > > What we would need in the echolink system ist hat you can announce yourself > to the system with a dtmf number ... >
|
|
Re: Cross linking (Was: Codec2)
"John" <john@...>
The D-STAR specification has a solution to this "non-issue" -- it involves a little MSK preamble on analog transmissions. http://www.d-star.asia/misc/shogen_4_2_8.pdf It seems in it's simplest form, one could use a PIC or Arduino and use UR:CQCQCQ with the MY set to the radio's callsign and put it in the TX audio and PPT lines for a radio, similar to what was done on APRS for voice (in fact add a GPS and send coordinates in a payload as well). For linking, this is all that is really needed. An analog repeater with a decoder would simply tell the linking system that the station whose callsign was in the MY field is present at that analog repeater. It you want directed traffic (callsign addressed), then a way to capture or set the UR callsign would be required.
--- In UniversalDigitalRadio@..., "siegfried jackstien" wrote:
> > What we would need in the echolink system ist hat you can announce yourself > to the system with a dtmf number ... >
|
|
AW: Cross linking (Was: Codec2)
"siegfried jackstien" <siegfried.jackstien@...>
What we would need in the echolink system ist hat you can announce yourself
toggle quoted messageShow quoted text
to the system with a dtmf number ... Example you are not at home but mobile in the range of any echolink node Give that node your node number (with a command before) that the system knows that you are not at home (reachable on your pc with your nodenumber) but that you are "in the system" known to be reachable via repeater xyz Now if any other wants to connect you then the system could answer with "your xall will be forwarded to repeater xyz" ... All echolink hams have a unique node number (that is your home pc) ... But all hams also can be called with their callsign number (there is a code for converting calls to dtmf numbers in echolink) So ... all the routing and callsign forwarding is there already in the echolink soft .... now what only is missing is that self-announce to the system while mobile and not connected with your home pc Ok ... no automatic routing like in a gsm net ... but something like "my-bbs" in the packet net .... Then integrating of some echolink nodes in the d-star (and maybe other) nets would be a lot easier Dg9bfc Sigi Ps we made some tests with short timings (set to min) and with all spoken things off (and no beeps etc.) with echolink .... nobody that did not know it would hear any difference in the audio quality!!
-----Ursprüngliche Nachricht-----
|
|
Re: Cross linking (Was: Codec2)
"Tony Langdon, VK3JED" <vk3jed@...>
At 12:35 PM 5/24/2012, you wrote:
The entire “MY� call is unenforceable. It I'm not sure where Australia stands on this. What I do know is that repeaters here are all considered "open", in that they must be available to all amateurs whose licence allows them access to the repeater. The reasoning is that because the repeater owner effectively has a frequency "reserved" for the repeater's operation (by licensing/coordination), then that resource must be available to all. Limiting access to a repeater by callsign would seem to fall foul of this principle as well. However, access to "additional features", such as IRLP, Echolink or other network access is not covered by these rules. Precedence was established by the ACMA fairly early on in the IRLP days, so it is legal for gateway owners to allow or block network access on a callsign or other basis as they see fit. Personally, I've always believed in open access and have run my systems as open access to all user functions (local and network). Seems as is common, Australia is somewhere between the US and Europe on this. 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
|
|
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)
"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)
"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)
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
|
|