Date   

Re: My ThumbDV won't work

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

On Sat, Mar 7, 2015 at 7:25 PM, ve3jx@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 

Hi John,


My ThumbDV works okay, but goes to sleep permanently when the PC goes into idle/sleep mode.  I am using WinDV and Windows 7.  The only way to 'wake' it up is to reseat it, or restart the PC.  Am I missing anything?


Cheers,


Dave Hayes VE3JX





--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223 
  


Re: My ThumbDV won't work

ve3jx@...
 

Hi John,


My ThumbDV works okay, but goes to sleep permanently when the PC goes into idle/sleep mode.  I am using WinDV and Windows 7.  The only way to 'wake' it up is to reseat it, or restart the PC.  Am I missing anything?


Cheers,


Dave Hayes VE3JX



ThumbDV & Win7

ve3jx@...
 

Greetings all,


I have a ThumbDV and just installed it this week.  Due to rather skimpy documentation, it took a little while to get it working right, especially with XRF reflectors.  It is doing fine right now.


The only quirk I notice is this:

When my PC goes to sleep, the communication between it and the ThumbDV gets 'broken' as well.  That is, when I "awaken" it, WinDV can't communicate with it on its COM4 port.  There are two ways I've found to bring it back:

(1) pull out and reseat the ThumbDV, or

(2) restart Windows.


Has anyone else had this problem?  Is there a better way of 'awakening' it?


Cheers,


Dave Hayes VE3JX



Re: How open are we?

myyahoo@...
 

OK, but in this case I believe that we're talking about making software available. :-)

My main point was that anyone (especially a commercial venture) who is getting themselves into a licencing situation should seek legal guidance to reduce the possibility of unintended future side effects. (With legal mumbo-jumbo, I'm convinced that it's impossible to completely eliminate *all* side effects - that's what keeps lawyers in Lamborghinis!)

My $WORK has a whole legal department to handle these issues - and even then they've had to clean up the company's act on occasion, especially after major acquisitions. I know that we avoid certain kinds of licences because the requirements don't meet our business objectives.

- Richard, VE7CVS


Re: How open are we?

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


On 2015-03-03 20:41, myyahoo@... [UniversalDigitalRadio] wrote:
...

Some licences (like most of the GPL variety) have a requirement that any modifications to source code be made available.

Not true (I contacted the Free Software Foundation about this some time ago).  You only have to make the source modifications available, if you make the software available.  You can take GPL-licensed software and make all the changes you want, and you don't have to tell anyone or make the changes available.  However, if you DO make the changes available (whether for free or for a price), then you have to make the source changes available as well.

Further, you don't have to make the changes available for free.  You can take GPL-licensed software, make some changes, and (with the source code), sell it for any amount you can get for it.  Usually, just once (ie, in a consulting contract), because you can't lay ANY restrictions on what the purchaser does with it.  The purchaser can sell it, or just give it away, and you have no recourse.

The idea (loosely stated) is that you get paid for your changes at most once (eg, consulting/development fees).

As an aside:  There is one portion of the GPL most people blindly apply, and that is the "version 2 or (at your option) any later version of the license" clause.  It's an insane provision, because it means that if the FSF decides (for money or as a legal mistake) to change the license that results in an unintended loophole that allows some entity to thwart the intent of an earlier version of the GPL, you are bound by it.  Most savvy developers restrict the GPL that they use to just version 2 or (the current) version 3.  The whole intent of the GPL is that no one can change the license without the contributors' permission.


Re: How Open? How Free? OpenBSD? NetBSD?

"Tyrell Jentink, KD7KUJ" <tyrell@...>
 

OK, I think I understand: As an OS developer, you find the lack of documentation on hardware to be a major restriction. I can understand that; I'm just not an OS developer, none of my code runs directly on the chip... And there isn't much I can't do in Linux. Honestly, the Raspberry Pi is as open as it's target audience actually needed.

I come from a Geography background, and the lack of openness in the GPS industry, particularly with regard to interfaces, is infuriating: Nothing is truly open, and the best one can hope for is a wide set of APIs typically found in only the most expensive units. Same thing with GSM modem chipsets; The Neo Freerunner was a completely open smartphone except for it's GSM baseband. At least those applications have military and FCC concerns to protect, and while I disagree, I can understand the perspective.

I am suspicious of the UDRX having similar problems, but am generally optimistic... Unlike GPS and GSM, Amateur Radio Operators are SUPPOSED to be trusted with the innards of our equipment. I might not be fully in the know, but I can't imagine anyone benefiting from NOT giving full access to the RF stack. Maybe I'm just not worrying enough.

On Mar 3, 2015 4:56 PM, "dsp_stap@... [UniversalDigitalRadio]" <UniversalDigitalRadio@...> wrote:


Re: How open are we?

myyahoo@...
 

The nice thing about licences is that there are so many to choose from - the downside of licences is that there are so many to choose from!

IMINWLO (In My In No Way Legal Opinion!), you should get a real lawyer (i.e., not one of us non-lawyers on the list or elsewhere) to translate the available licences for you to digest. They have various uses and pitfalls, with features that prevent or enable other commerical entities to use your code (which you may/may not want to happen) and permit or restrict other noncommercial uses. In addition to GPL, another popular type of licence is Apache. FSF (the Free Software Foundation) is also a good place to look for pointers.

You may also have the choice of applying more than one licence at a time, letting the user choose which is applicable to them. You may even be able to add more licences over time, but I don't think you can recind licences for already distributed code (but may be able to change them for new versions).

Some licences (like most of the GPL variety) have a requirement that any modifications to source code be made available. There are usually (notice that I'm using 'weasel-words' to prevent being tagged with giving legal advice that I'm not legally competent or licenced to give :-) ways for you to permit open use by the community while still reserving commercial use to more restrictive licencing - if you so choose.

The bottom line is - get a lawyer who is working for your best interests to help determine how you want to licence your property, it will cost you less in lawyer fees (the only ones who really make money from most licences!) in the long run. Some licences have more 'overhead' to maintain than others, which might be a burden to your company (something that I really don't want to see!).

- Richard


Re: PHY Layer Protocols

myyahoo@...
 

Not all services will need FEC, some are more fault tolerant than others. I would say that FEC at the lowest level should be optional - at best, and than it could certainly be incorporated at a higher level for applications least tolerant to packet loss. Fixed-to-fixed services are much less likely to benefit from FEC, while I can see that mobile apps may benefit from it.

At these speeds, interference is likely to impact more that the occasional single bit, which is why FEC overhead may not be worth the trouble.

I can say that from previous experience at 56 kbps on 70 cm (both fixed and mobile), packet loss was very low, and giving up even 10% to FEC would have been wasteful - for typical terminal sessions. Encoding voice in a more resilient way, including either FEC or other tricks (silence/replication for lost segments) could provide a better experience.

But I wouldn't make FEC at the packet level a mandatory requirement until shown to be necessary after real world testing. Leaving it to the higher levels would also mean that the most appropriate form of FEC could be tailored to each application.

High speed/high tolerance for error (e.g., compressed video?) may suffer more from FEC than would be gained, where slower speed/low tolerance for error applications would cause little extra channel overhead while using FEC. Each application could get the FEC that it needs (or doesn't need).

From the earlier desciption, that's basically the D-Star approach.
 
- Richard, VE7CVS


Re: My ThumbDV won't work

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

Use the contact information on DUTCH*Star site to ask Fred for the beta, e.g. send him an email.

On Tue, Mar 3, 2015 at 4:57 PM, tom@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 

thanks for your help - I did what you suggested and the ThumbDV is being seen after all - but I cannot find the WIN DV Beta 1.5.8 - I did find V1.5.7 Updated under Dutch Star DV Mode -I don't understand what you mean about "you have to ask for it?" again thanks!

__._,_.
--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223 
  


Re: My ThumbDV won't work

tom@...
 

thanks for your help - I did what you suggested and the ThumbDV is being seen after all - but I cannot find the WIN DV Beta 1.5.8 - I did find V1.5.7 Updated under Dutch Star DV Mode -I don't understand what you mean about "you have to ask for it?" again thanks!


Re: How Open? How Free? OpenBSD? NetBSD?

dsp_stap@...
 


---In UniversalDigitalRadio@..., <tyrell@...> wrote :
> What's wrong with the Raspberry Pi?

No documentation.  Closed proprietary interfaces.

https://marc.info/?l=openbsd-misc&m=132788027403910&w=2
https://marc.info/?l=openbsd-misc&m=132794042820760&w=2
https://marc.info/?l=openbsd-misc&m=135109499020826&w=2
http://whitequark.org/blog/2012/09/25/why-raspberry-pi-is-unsuitable-for-education/

73,
Ken N8KH

 

PS  A closed proprietary interface is an inherent contadiction.



Re: My ThumbDV won't work

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

Tom,

The tools NAWinConfig and NAWinTest are for testing Node Adapters and not USB attached AMBE devices like the ThumbDV.

Open the program "Device Manager" and go to the COM/LPT list.  Plug the ThumbDV in and see if a new "USB Serial" device shows up and note its number, e.g. COM4, and unplug it and see if it disappears from the list.  If it appears and disappears, your computer is seeing it.

Go to WinDV (be sure you have the beta 1.5.8-x from DUTCH*Star -- you have to ask for it) and select the ThumbDV and configure it to use the COM port you see in the list. (DVTool has not been modified to support ThumbDV)

If the ThumbDV not showing up, it's possible that the driver didn't install.  You will note on the http://nwdigitalradio.com/thumbdv-and-dv3000-resource-page page there is a link to get the drivers directly from FTDI.




On Tue, Mar 3, 2015 at 4:01 PM, tom@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 

I can’t get my ThumbDV to work.  Apparently, my computer cannot see it.  My friends report that when they plugged their ThumbDV into a WinBook 700 it automatically installed drivers, etc.  Mine did nothing when I plugged it in.


I have tried it on my WinBook 700 (its operating system is Windows 8.1); a desktop running Windows 7; and also a Dell laptop running XP, with no luck. I also tried running the ThumbDV on my wife’s WinBook700 to no avail.


When I run NAWinConfig or NAWinTest, I get the error message is, “node adapter not detected.”


 Does it sound like something is wrong with the ThumbDV or am I missing a step in installation?


BTW, I can operate my DVDongle (using DVTool) with the WinBook, no problem...


73 Tom



--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223 
  


My ThumbDV won't work

tom@...
 

I can’t get my ThumbDV to work.  Apparently, my computer cannot see it.  My friends report that when they plugged their ThumbDV into a WinBook 700 it automatically installed drivers, etc.  Mine did nothing when I plugged it in.


I have tried it on my WinBook 700 (its operating system is Windows 8.1); a desktop running Windows 7; and also a Dell laptop running XP, with no luck. I also tried running the ThumbDV on my wife’s WinBook700 to no avail.


When I run NAWinConfig or NAWinTest, I get the error message is, “node adapter not detected.”


 Does it sound like something is wrong with the ThumbDV or am I missing a step in installation?


BTW, I can operate my DVDongle (using DVTool) with the WinBook, no problem...


73 Tom



Re: PHY Layer Protocols

Michael E Fox - N6MEF <n6mef@...>
 

Yup.  And according to what I've read about FX.25, it's evidently backwards compatible with AX.25.  So while a more sophisticated, dynamic approach would be nice, it seems like something simple like FX.25 would allow us to deploy.

M



Sent from my Verizon Wireless 4G LTE smartphone


-------- Original message --------
From: "Bill Vodall wa7nwp@... [UniversalDigitalRadio]"
Date:03/03/2015 3:42 PM (GMT-08:00)
To: UniversalDigitalRadio@...
Subject: Re: [UniversalDigitalRadio] Re: PHY Layer Protocols

 

> On many (most?) real-world channels, you will get single bit errors, causing the whole packet to be retransmitted.

Since we have the source, it should be possible to add the bad-bit
correction that's been successfully implemented in both UZ7HO and DIRE
WOLF software modems.

Also there's the FX25 project adding FEC to AX25 that could be looked at...

http://www.stensat.org/docs/FX-25_01_06.pdf

Bill


Re: PHY Layer Protocols

Bill Vodall <wa7nwp@...>
 

On many (most?) real-world channels, you will get single bit errors, causing the whole packet to be retransmitted.
Since we have the source, it should be possible to add the bad-bit
correction that's been successfully implemented in both UZ7HO and DIRE
WOLF software modems.

Also there's the FX25 project adding FEC to AX25 that could be looked at...

http://www.stensat.org/docs/FX-25_01_06.pdf

Bill


Re: PHY Layer Protocols

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

True.  But the problem is, many (most?) “real world” channels in a metro area (<25 miles) are NOT “nearly loss-less”.   On many (most?) real-world channels, you will get single bit errors, causing the whole packet to be retransmitted.  Longer packets = greater probability of error.  Shorter packets = more header overhead.  End result is still lower throughput (often much lower) than with FEC.  It’s not a hard test to duplicate with 9600 baud packet.  It’s also not hard to duplicate with commercial digital radios although it does require a rather expensive analyzer to see the data.  That’s why the commercial digital radio world uses FEC.  The whole rest of the world is not wrong.

 

So, yes, it’s overhead and yes, we need it. 

 

Michael

N6MEF

 

From: UniversalDigitalRadio@... [mailto:UniversalDigitalRadio@...]
Sent: Tuesday, March 03, 2015 7:56 AM
To: UniversalDigitalRadio@...
Subject: [UniversalDigitalRadio] Re: PHY Layer Protocols

 

 

FEC is just overhead unless you really need it. On nearly loss-less channels (which is what we should expect on short haul 70 cm links), you lose more throughput than you gain with FEC.


Re: PHY Layer Protocols

Jim Alles <kb3tbx@...>
 

I am just lurking in this group, but consider this:

Wireless HART is a channel-hopping mesh network, and utilizes a network manager. It does not fit the use-case, but there might be some interesting ideas.

I have additional PDFs if anyone is interested.

Jim Alles, KB3TBX
Penn State Univ. DDC technician


Re: PHY Layer Protocols

Marshall Denny <MarshallDenny@...>
 

Consider that we could have multiple levels of FEC including none with the receiver being able to decode any of the available options.

1. UI/UDP broadcast could use strong FEC
2. Initial connection modes could start with strong FEC and then switch to low FEC or no FEC based on conditions of the specific link.

In general, consider using "and" rather than "or" in these types of situations, we have the potential of a lot more flexibility today than in the past.  

The memory available in a  raspberry pi compared to a TNC of the past is the difference between night and day.




Respectfully,
Marshall Denny
Technical Architect, Contractor
AT&T
425 288 6443 office
206 842 9305 home
206 734 9242 cell

Politicians and diapers should be changed frequently and for the same reason.
-- unknown

On Tue, Mar 3, 2015 at 7:56 AM, myyahoo@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 

FEC is just overhead unless you really need it. On nearly loss-less channels (which is what we should expect on short haul 70 cm links), you lose more throughput than you gain with FEC. If we were talking about long haul lossy links (as on HF), then FEC can be a winner. This is a reason that D-Star does not use FEC (and no one is complaining about packet loss there), and I don't believe that we'll need it for most applicaitons either. Time will tell, and there's nothing stopping anyone from comparing FEC to non-FEC transmissions and measuring it in real life...

You ask some interesting questions about channel allocation and use - I doubt that we will settle this before the radio ships, it is something that I know that I will be experimenting with - and I know that others will be doing the same. The beauty of SDR is that the standard doesn't need to be cast in stone, and there may be reasons for more than one standard depending on the network topology (a few stations scattered along a long distance may need a different solution than a city full of adjacent stations). Even after the first standard(s) are in place, if experimentation comes up with a better scheme some time later - it's trivial to load new software and reinvent the entire network!

As to channel allocation, one suggestion is to use an ISDN-like approach, with a fixed, narrow control channel that does all (or most) of the channel assignments, and then the rest of the bandwidth can be sliced-and-diced as needed. Deciding how this is coordinated among stations that do not have complete connectivity with one another (a distributed mesh) is one of the issues that needs to be tackled - but there are some simple allocation schemes that can be used to start. I certainly don't want to see a master/slave approach, but more like 'cooperating masters', where every station is part of the control puzzle. Some heuristics can be built to map the network and determine how to best use the channels at any given time, and give appropriate QOS based on the type of traffic - e.g., audio traffic is much more sensitive to latency than email or SSH connections.

- Richard, VE7CVS



Re: PHY Layer Protocols

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



On Mon, Mar 2, 2015 at 5:26 PM, dsp_stap@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 
> ... create more robust and efficient air protocols,
> e.g. forward error correction, header compression ...

Really? D-Star has no FEC??  I'm shocked!!  (And horrified!)  If it were possible, I would now have an even lower opinion of D-Star than I had in the past.


D-STAR does use FEC in the AMBE sub-frames, but it was not specified for the entire packet or payload.  The D-STAR Data (DD) implementation simply wraps Ethernet frames and does not have FEC.

--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223 
  


Re: How Open? How Free? OpenBSD? NetBSD?

"Tyrell Jentink, KD7KUJ" <tyrell@...>
 

>Otherwise, I must assume that you have a Raspberry Pi situation.

What's wrong with the Raspberry Pi? The best I can tell, this sums it up well, and I don't see a real problem: http://www.raspberrypi.org/forums/viewtopic.php?t=55777&p=422729

Don't get me wrong, I hate Broadcom and ARM Holdings as much as the next guy, and I'm aware of the bugs in the OpenGL ES implementation, but I also recognize that I, as a mere mortal, can't do anything about it: I don't have the capability to cast a new die that fixes those problems, so I don't have to care. I guess it would be nice to be able to find said bugs and tell Broadcom how to fix them, but I don't need that capability to write cool software.