Date   

ThumbDV and WinDV 1.5.8

ka1mxl@...
 

Does anyone have acopy of this software or have any idea how I can get a copy. I recently purchased the ThumbDV, watched the youtube video like 6 times and now I find out that you cannot use the software from the download page. One would thnk that the mfg. would point this out!


Thanks for any and all help.


Kevin KA1MXL


Re: UDRX, LinBPQ and 9600

"John Wiseman" <john.wiseman@...>
 

I’m pretty sure there will be a version of LinBPQ for the UDRX as soon as I can get my hands on one!

 

73, John G8BPQ

 


From: UniversalDigitalRadio@... [mailto:UniversalDigitalRadio@...]
Sent: 03 April 2015 18:24
To: UniversalDigitalRadio@...
Subject: [UniversalDigitalRadio] UDRX, LinBPQ and 9600

 

 

One of the things I'd like to do with a UDRX is run a remote 9600 packet node. I'm not sure how the 9600 baud functionality is supported within the radio but would it be possible to also load LinBPQ in order to run a NetRom node? 

 

73, Steve KB1TCE


UDRX, LinBPQ and 9600

shansen@...
 

One of the things I'd like to do with a UDRX is run a remote 9600 packet node. I'm not sure how the 9600 baud functionality is supported within the radio but would it be possible to also load LinBPQ in order to run a NetRom node? 


73, Steve KB1TCE


Re: DV3000

Mike Lussier <mike.lussier@...>
 

Great to see some software written to encode decode Fusion system

Mike AE4ML

--
"We must reject the idea that every time a law is broken, society is guilty rather than the law breaker.It is time to restore the American precept that each individual is accountable for his actions." ~ Ronald Regan



Re: DV3000

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

Yes.

The FEC in built into the data stream by the chip, so you don't need to do anything additional for FEC.  

There is no existing program to do it, but it would be pretty straight forward.  The analog audio and AMBE go in and out of the chip (on the DV3000 or ThumbDV) over a UART interface.  You would just need to setup a program that listened for AMBE on a UDP socket and sent it to the DV3000 and take the returned audio packets and send them to your audio interface.  (UDP is preferred for real time audio.)

If you would like to write something, a good place to start would be https://github.com/dl5di/OpenDV/tree/master/DummyRepeater/DV3000  the AMBEserver code is there.  Look at dv3000d.c

Here is the manual on programming the chip http://www.dvsinc.com/manuals/AMBE-3000F_manual.pdf

On Tue, Mar 31, 2015 at 9:21 PM, brizey02@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 

Is it possible to just use the DV3000 to vocode auduio and pass it via TCP or UDP over a network? or would it need FEC and sync bits and such.




--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223 
  


Re: DV3000

Bernd - OE7BSH <oe7bsh@...>
 

Hi,

On 01.04.2015 06:21, brizey02@... [UniversalDigitalRadio] wrote:


>Is it possible to just use the DV3000 to vocode auduio and pass
>it via TCP or UDP over a network? or would it need FEC and sync bits and such.

_,_._,___

yes, this is possible.   I used a DV3000 on a pi in my network here to stream the decoded data to a Win laptop with ircddbgateway and dummy repeater. Dummy repeater offers a device setting "dv 3000 via network"
73 de Bernd, OE7BSH
-- 
==================================
oe7bsh@... // http://www.qth.at/oe7bsh
Kitzbühel JN67EK // PGP-ID: 0xCE5C3B36
Repeater als App: http://www.repeaterbook.com
================================== 


DV3000

brizey02@...
 

Is it possible to just use the DV3000 to vocode auduio and pass it via TCP or UDP over a network? or would it need FEC and sync bits and such.


Re: 44 addresses / JNOS 56K / Gateway Security ?

myyahoo@...
 

Hey, we Canadians are known for being laid back! :-)

Maybe me a little less so, having been in California for almost 17 years...

I would poke at them again. I may still have a 44.x net allocation on the Vancouver 56kbps network (VE7RYY and VE7RYZ). You do need a new subnet for the new network if you're going to route IPv4 there. I need to read up on IPv6-to-4 NAT. Since an IPv6 subnet is the size of the entire IPv4 network it should be possible to 'just' map the 44.x subnet addresses into the IPv6 subnet, at least until we have IPv6 routing in general use on the Internet. IPv4 compatibility is going to be necessary for some years to come (at least the next decade).

You might contact one of the local BC subnet owners to see if they can help. I see 'VE7HEX' at UBC (they had a lot of club activity some years ago, hope they're still hopping), or VE7ASS (yes, Canada did issue that callsign! ;-) ), Jerome is quite a character...

VE7WNK and VE7RRX are also listed in the Lower Mainland.

I guess that I should also apply for a 44.x subnet for UDRX work in San Jose - wish me luck!

- Richard, VE7CVS    


---In UniversalDigitalRadio@..., <ve7dhm@...> wrote :

Well this thread has taken on a new life...so be it.

Still waiting for a 44 address allocation.  A little disappointing in the slow response.  Maybe just a Canadian
thing!

Paul VE7DHM


UDRX hardware / software expectations

ve7dhm@...
 

- to be available in the very near future as previous posts have indicated testing is done
- hardware to support a linux version that has good library support for all things Amateur Radio
- to be shipped with some ready to run tested applications to confirm the UDRX is working
- hardware does NOT have to be MIL-SPEC for temperature, humidity, shock etc.  That drives up
  the cost tremendously
- it would be nice if the modem, CPU and RF deck were easy to swap out in case of failure
- I do expect that updated versions of the UDRX will follow just like all the other electronic devices
  ...computers, tablets, cell phones...that are used in our daily lives.  If the original UDRX version
  does not meet future application requirements then I expect to have to upgrade or purchase a new
  version of the UDRX

So are any of the above a show stopper in getting the box out the door and if so when?



Re: 44 addresses / JNOS 56K / Gateway Security ?

"Michael E Fox \(N6MEF\)" <n6mef@...>
 

If you’re not getting a response from your AMPRnet address coordinator, you can ask for help from other folks on the 44-net mailing list.  Anyone who’s running an AMPRnet gateway really should be on that list anyway.

 

http://hamradio.ucsd.edu/mailman/listinfo/44net

 

Michael

N6MEF

 

 

Well this thread has taken on a new life...so be it.

Still waiting for a 44 address allocation.  A little disappointing in the slow response.  Maybe just a Canadian
thing!

Paul VE7DHM


Re: 44 addresses / JNOS 56K / Gateway Security ?

ve7dhm@...
 

Well this thread has taken on a new life...so be it.

Still waiting for a 44 address allocation.  A little disappointing in the slow response.  Maybe just a Canadian
thing!

Paul VE7DHM


Re: 44 addresses / JNOS 56K / Gateway Security ?

Dean Gibson AE7Q <yahu.stuff@...>
 

Oops, yes, I do!  Thanks for the correction!

I blame my keyboard's firmware for the typing error;  it's not open source ...

On 2015-03-29 13:02, Matthew Pitts daywalker_blade_2004@... [UniversalDigitalRadio] wrote:
Dean, Do you mean the Free Software Foundation?

Matthew Pitts N8OHU
 

From: "Dean Gibson AE7Q yahu.stuff@... [UniversalDigitalRadio]"
To: UniversalDigitalRadio@...
Sent: Sunday, March 29, 2015 3:01 PM
Subject: Re: [UniversalDigitalRadio] 44 addresses / JNOS 56K / Gateway Security ?

On 2015-03-29 10:13, Jonathan Naylor naylorjs@... [UniversalDigitalRadio] wrote:
Why does it matter?

...

Your purist viewpoint is the antithesis of actually getting things done, which is the main purpose of most things that we do as amateurs.

Jonathan  G4KLX


What is COMICAL about the position of the Electronic Frontier Foundation ("EFF", the creators of the GPL), is ...


Re: UDRX Processor Board

Steve Stroh N8GNJ <steve.n8gnj@...>
 

Richard:

What was the attachment method for the SSD - USB?

Thanks,

Steve N8GNJ

On Sun, Mar 29, 2015 at 8:16 AM, myyahoo@...
[UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:



I've worked with computer systems in humid environments that make anything in North America look 'arid'. :-)

Fiji, Tonga, and Samoa are much, much more challenging! You have no idea...

For storage - I run my household-network Raspberry Pi on a commercial SSD. No SD card or USB flash can stand up to the hammering that a busy Pi does to its filesystem on a 24/7 basis. Tried both.

However, my Pi does DNS, DHCP, HTTP, and email for my home, so there's a lot of file writing going on - and those files need to be persistent. It's quite possible to make a Pi with an SD card work perfectly well for an application like UDRX - it is not difficult to put all of the high-change files in a RAM disk, only some minor Linux tweaking is required. An SD card works fine if updates are not happening frequently, my Pi still boots from an SD. Occasional writes to the SD to update software and alter configurations wouldn't be problematic, I would expect an SD card to survive for many years, probably on the same order (and cost) of lithium ion cells found in many radios.

This is going to be true for any embedded-linux device that the project is looking at using. We need essentially flash+RAM, which can be done with the Pi. Adding a commercial SSD to any of these configurations will blow the budget for the device, although I would expect that anyone who finds a need to add SSD for additional persistent storage can do it through the USB port (that's how I connect mine on a Pi).

- Richard, VE7CVS


Re: 44 addresses / JNOS 56K / Gateway Security ?

Matthew Pitts <daywalker_blade_2004@...>
 

Dean,

Do you mean the Free Software Foundation?

Matthew Pitts
N8OHU
 



From: "Dean Gibson AE7Q yahu.stuff@... [UniversalDigitalRadio]" <UniversalDigitalRadio@...>
To: UniversalDigitalRadio@...
Sent: Sunday, March 29, 2015 3:01 PM
Subject: Re: [UniversalDigitalRadio] 44 addresses / JNOS 56K / Gateway Security ?

 

On 2015-03-29 10:13, Jonathan Naylor naylorjs@... [UniversalDigitalRadio] wrote:
Why does it matter?

...

Your purist viewpoint is the antithesis of actually getting things done, which is the main purpose of most things that we do as amateurs.

Jonathan  G4KLX


What is COMICAL about the position of the Electronic Frontier Foundation ("EFF", the creators of the GPL), is that they have created an "LGPL" ("Lesser GPL") for use in distributing libraries.  They really don't want you to license any library you create under the LGPL,  they really would like you to use the regular GPL (see https://www.gnu.org/licenses/why-not-lgpl.html ).  They provide the LGPL for purely pragmatic reasons (ie, competition from other libraries), and it's not just that they want others to do it;  they bow to this pragmatic situation for some of their own libraries.  Because if you use their libraries and then distribute your own software, they want you to have to release all of your own source code, just because you link to their libraries.  This is a religion.

So much for "purism" , "ethics", and "evil".  Richard Stallman (the creator of the EFF: http://en.wikipedia.org/wiki/Richard_Stallman -- yes, a Snowden supporter) likes to couch his beliefs about "open source" software with words like "Freedom" (note the capitalization) and "evil".  Ken has swallowed the GPL KoolAid.

OK, they are entitled to license their libraries in any way then want.  However, other developers are not such fools.  In particular, the "RxTx" communications library is not only licensed under the LGPL, the creators (having no association with the EFF) added clauses to the LGPL license to make sure that there was no misunderstanding in regard to their software:  They allow library users of the RxTx library, to link to the library, and the user is not bound to any license for the user's software.  In other words, common sense.

Of course, the average amateur doesn't give a darn for the true value of "open source" software.  Since it is almost impossible to sell "open source" software for anything above the cost of the media, that means that the software is free in the economic sense, and that's what appeals to 99% of those that use "open source" software.  There is that old saying, "Copper wire was invented by two amateurs fighting over a penny."

Why do I say 99% (it's probably closer to 99.99%)?  Because of the several GPL packages I have released, I have never heard of anyone wanting to modify a single line of code.  One package, "SeaFlow" was wildly popular in the previous decade among Linux and Mac owners, because SeaFlow supplanted a Windows-only package ("WebFlow")from the Washington state Department of Transportation, and I received many enthusiastic complements, and a couple suggestions for modifications (they wanted me to do them), but no questions about the source after I released it.

Of the several GPL packages I released for the amateur community, the only feedback I've gotten, is that they are "too difficult to use".  A command-line program with no options is "too difficult to use"???

Entitlement abounds everywhere, I've discovered (just ask Dan Smith, the creator of "Chirp" and "D-Rats").  They should sell their $30 radios and go back to adding lights to their trucks.

-- Dean Gibson



Re: 44 addresses / JNOS 56K / Gateway Security ?

Dean Gibson AE7Q <yahu.stuff@...>
 


On 2015-03-29 10:13, Jonathan Naylor naylorjs@... [UniversalDigitalRadio] wrote:
Why does it matter?

...

Your purist viewpoint is the antithesis of actually getting things done, which is the main purpose of most things that we do as amateurs.

Jonathan  G4KLX


What is COMICAL about the position of the Electronic Frontier Foundation ("EFF", the creators of the GPL), is that they have created an "LGPL" ("Lesser GPL") for use in distributing libraries.  They really don't want you to license any library you create under the LGPL,  they really would like you to use the regular GPL (see https://www.gnu.org/licenses/why-not-lgpl.html ).  They provide the LGPL for purely pragmatic reasons (ie, competition from other libraries), and it's not just that they want others to do it;  they bow to this pragmatic situation for some of their own libraries.  Because if you use their libraries and then distribute your own software, they want you to have to release all of your own source code, just because you link to their libraries.  This is a religion.

So much for "purism" , "ethics", and "evil".  Richard Stallman (the creator of the EFF: http://en.wikipedia.org/wiki/Richard_Stallman -- yes, a Snowden supporter) likes to couch his beliefs about "open source" software with words like "Freedom" (note the capitalization) and "evil".  Ken has swallowed the GPL KoolAid.

OK, they are entitled to license their libraries in any way then want.  However, other developers are not such fools.  In particular, the "RxTx" communications library is not only licensed under the LGPL, the creators (having no association with the EFF) added clauses to the LGPL license to make sure that there was no misunderstanding in regard to their software:  They allow library users of the RxTx library, to link to the library, and the user is not bound to any license for the user's software.  In other words, common sense.

Of course, the average amateur doesn't give a darn for the true value of "open source" software.  Since it is almost impossible to sell "open source" software for anything above the cost of the media, that means that the software is free in the economic sense, and that's what appeals to 99% of those that use "open source" software.  There is that old saying, "Copper wire was invented by two amateurs fighting over a penny."

Why do I say 99% (it's probably closer to 99.99%)?  Because of the several GPL packages I have released, I have never heard of anyone wanting to modify a single line of code.  One package, "SeaFlow" was wildly popular in the previous decade among Linux and Mac owners, because SeaFlow supplanted a Windows-only package ("WebFlow")from the Washington state Department of Transportation, and I received many enthusiastic complements, and a couple suggestions for modifications (they wanted me to do them), but no questions about the source after I released it.

Of the several GPL packages I released for the amateur community, the only feedback I've gotten, is that they are "too difficult to use".  A command-line program with no options is "too difficult to use"???

Entitlement abounds everywhere, I've discovered (just ask Dan Smith, the creator of "Chirp" and "D-Rats").  They should sell their $30 radios and go back to adding lights to their trucks.

-- Dean Gibson


Re: 44 addresses / JNOS 56K / Gateway Security ?

Matthew Pitts <daywalker_blade_2004@...>
 

Well said, Jonathan. Yes, there might be times when a pure system is desired, but it should not be the sole criteria used to choose a piece of hardware; to me, a situation where a few binary blobs that might or might not be used is acceptable if the hardware chosen is otherwise suitable to the task that it's being put to and being chosen because it is the most cost effective option that does the job required.

Matthew Pitts
N8OHU



From: "Jonathan Naylor naylorjs@... [UniversalDigitalRadio]"
To: "UniversalDigitalRadio@..."
Sent: Sunday, March 29, 2015 1:13 PM
Subject: Re: [UniversalDigitalRadio] 44 addresses / JNOS 56K / Gateway Security ?

 
Why does it matter?

As an open source developer, my main concern is having a sane development and run-time environment. The purpose of the OS is to disguise all of the details of the hardware and provide abstractions for them. The fact that a video chip or anything else is closed is of no matter as long as it works with our OS of choice.

Your purist viewpoint is the antithesis of actually getting things done, which is the main purpose of most things that we do as amateurs.

Jonathan  G4KLX




From: "dsp_stap@... [UniversalDigitalRadio]"
To: UniversalDigitalRadio@...
Sent: Sunday, 29 March 2015, 16:20
Subject: Re: [UniversalDigitalRadio] 44 addresses / JNOS 56K / Gateway Security ?

 
---In UniversalDigitalRadio@..., John Hays K7VE wrote :
>Please be aware, there is no graphics display
> on the UDRX-440 -- so graphics capability is
> not something on our checklist.

And thus the release of the source code for the graphics stack for the BCM21553 cellphone chip doesn't matter for the UDRX project, and it doesn't help.

But the documentation and source code which is still being withheld does matter, and is harmful, should you choose a product with Broadcom hardware.

Choose wisely.

73,
Ken N8KH






Re: 44 addresses / JNOS 56K / Gateway Security ?

Jonathan Naylor <naylorjs@...>
 

Why does it matter?

As an open source developer, my main concern is having a sane development and run-time environment. The purpose of the OS is to disguise all of the details of the hardware and provide abstractions for them. The fact that a video chip or anything else is closed is of no matter as long as it works with our OS of choice.

Your purist viewpoint is the antithesis of actually getting things done, which is the main purpose of most things that we do as amateurs.

Jonathan  G4KLX



From: "dsp_stap@... [UniversalDigitalRadio]" <UniversalDigitalRadio@...>
To: UniversalDigitalRadio@...
Sent: Sunday, 29 March 2015, 16:20
Subject: Re: [UniversalDigitalRadio] 44 addresses / JNOS 56K / Gateway Security ?

 
---In UniversalDigitalRadio@..., John Hays K7VE wrote :
>Please be aware, there is no graphics display
> on the UDRX-440 -- so graphics capability is
> not something on our checklist.

And thus the release of the source code for the graphics stack for the BCM21553 cellphone chip doesn't matter for the UDRX project, and it doesn't help.

But the documentation and source code which is still being withheld does matter, and is harmful, should you choose a product with Broadcom hardware.

Choose wisely.

73,
Ken N8KH




Re: UDRX Processor Board

dsp_stap@...
 

---In UniversalDigitalRadio@..., Richard VE7CVS <myyahoo@...> wrote :
>Adding a commercial SSD to any of
> these configurations will blow the
> budget for the device, although I
> would expect that anyone who finds
> a need to add SSD for additional
> persistent storage can do it through
> the USB port (that's how I connect
> mine on a Pi).

The board will also have ethernet, so NFS filesystems can be mounted.

Ethernet is really a must have.  It allows mounting the radio remotely -- up to a few hundred feet.  USB doesn't allow that.

73,
Ken N8KH


Re: 44 addresses / JNOS 56K / Gateway Security ?

dsp_stap@...
 

---In UniversalDigitalRadio@..., John Hays K7VE <john@...> wrote :
>Please be aware, there is no graphics display
> on the UDRX-440 -- so graphics capability is
> not something on our checklist.

And thus the release of the source code for the graphics stack for the BCM21553 cellphone chip doesn't matter for the UDRX project, and it doesn't help.

But the documentation and source code which is still being withheld does matter, and is harmful, should you choose a product with Broadcom hardware.

Choose wisely.

73,
Ken N8KH


Re: UDRX Processor Board

myyahoo@...
 

I've worked with computer systems in humid environments that make anything in North America look 'arid'. :-)

Fiji, Tonga, and Samoa are much, much more challenging! You have no idea...

For storage - I run my household-network Raspberry Pi on a commercial SSD. No SD card or USB flash can stand up to the hammering that a busy Pi does to its filesystem on a 24/7 basis. Tried both.

However, my Pi does DNS, DHCP, HTTP, and email for my home, so there's a lot of file writing going on - and those files need to be persistent. It's quite possible to make a Pi with an SD card work perfectly well for an application like UDRX - it is not difficult to put all of the high-change files in a RAM disk, only some minor Linux tweaking is required. An SD card works fine if updates are not happening frequently, my Pi still boots from an SD. Occasional writes to the SD to update software and alter configurations wouldn't be problematic, I would expect an SD card to survive for many years, probably on the same order (and cost) of lithium ion cells found in many radios.

This is going to be true for any embedded-linux device that the project is looking at using. We need essentially flash+RAM, which can be done with the Pi. Adding a commercial SSD to any of these configurations will blow the budget for the device, although I would expect that anyone who finds a need to add SSD for additional persistent storage can do it through the USB port (that's how I connect mine on a Pi).

- Richard, VE7CVS