Hi John, We've been thinking about some of these ideas as well. In the design of the UDR56K-4 we really are shooting for the "sweet spot" between data rate, bandwidth, propagation, and utility. 70cm

Hi Brian, There will be APIs. We are busy in development right now, and will be focusing on getting the radio ready for market. We encourage development for this device, hence the high use of FOSS

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

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

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

Yes we are using Paclink Unix and Linux RMS. We have had interest from European distributors but will not have them set-up for first delivery. Best regards to your sister, Bryan

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

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

David, 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?

Do you have any plans to be compatible with DD-WRT? Thank you, David, W2LNX

I'll post an app note on using the UDR56K with the Winlink system next week, including screen shots. Bryan

Are there any screen shots of the Universal Radio software? Greg

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

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,

What we would need in the echolink system ist hat you can announce yourself to the system with a dtmf number ... Example you are not at home but mobile in the range of any echolink node Give that

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

At 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

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.

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

Matthew, 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