[digitalradio] Re: Test version of Multipsk about ARQ FAE in ALE400

2009-09-15 Thread mikenetbot
Wow Patrick, you're really on top of things tweaking this mode. Good job!

Could you explain in more detail with the "asymmetry Slave/master is increased" 
means? Was the timing of the mode altered? 

--- In digitalradio@yahoogroups.com, "Patrick Lindecker"  wrote:
>
> Hello to all testers,
> 
> Following the previous tests (which target continues to be to test the 
> reconnection in case of QRM, QSB...), I have issued a new test version about 
> ARQ FAE in ALE400,
> Modifications: 
> * I've reduced the detected bandwith to +/-120 Hz to avoid any off band RS ID,
> * the asymetry Slave/master is increased,
> * RS ID is sent at retry 3, 5, 7...
> 
> Here is the Multipsk test version: 
> http://f6cte.free.fr/MULTIPSK_TEST_15_09_2009.ZIP
> 
> Paste this adress in your Internet Explorer or equivalent. Download the file.
> Create a tempory folder (C:\TEST, for example), unzip the file in it and 
> start C:\TEST\Multipsk.exe (the auxiliary files will be created 
> automatically). 
> 
> 
> For ALE and ALE400, see:
> http://f6cte.free.fr/ALE_and_ALE400_easy_with_Multipsk.doc
> http://f6cte.free.fr/The_ARQ_FAE_beacon_easy_with_Multipsk.doc
> 
> Experimentation of the ARQ FAE / ALE400
> For experimention, once connected, it would be useful to send something, to 
> slighltly change the reception frequency (to create a problem) and to see how 
> works the reconnection. It would be also interesting to stop the TX power for 
> about 10 seconds to see how it reconnects afterwards. Normally, it must 
> reconnect for a S/N >= -10 dB (the S/N measure is near the top bar of the 
> "Aux. functions" window).
> 
> I will call, to-night, on 3585 KHz USB HF 1000 Hz AF +/- QRM, in ARQ FAE / 
> ALE400 for QSO since 20h00 UTC until 20h30 UTC.
> PSE push on the "RX RS ID" button. 
> 
> Hint: on the waterfall, the beginning of ALE400 transmission seems to be 2 
> paws with 3 nails on each paw.
> If the AF frequency is well adjusted, the 2 blue vertical dashes must 
> normally coincide with the 2 central  nails.
> 
> 73
> Patrick
>




[digitalradio] Re: PSK-PACKET anyone? - Description

2009-08-31 Thread mikenetbot
Has anyone tried keyboard-to-keyboard connected BPSK63? (I assume that it is 
connected and not UI, as we are talking about the FRACK option).

Also, am I correct that PAX/PAX2 will run in connected mode? For some reason I 
thought they were UI-only, but now I cannot tell. 

I'm interested in these soundcard ARQ modes.

--- In digitalradio@yahoogroups.com, "Patrick Lindecker"  wrote:
>
> Hello Ian,
> 
> Here is some information about PSK Packet.
> 
> Important: in BPSK63 Packet, set the FRACK option at, at least, 8 seconds 
> (the standard 5 sec is not sufficient).
> 
> 73
> Patrick
> 
> 
> Coding/Decoding of Packet BPSK1200 and new modes Packet BPSK250 and BPSK63
> The BPSK1200 Packet mode is used for satellite (as LUSAT LO-19 for example) 
> transmissions in UHF (USB). But it could also be used in VHF (FM ) with a 
> better performance than Packet FSK, in Unproto (APRS) or in connected mode.
> 
> The BPSK250 and BPSK63 Packet modes are experimental and could be used 
> favourably for APRS transmissions in HF.
> 
> Description of the PSK Packet 1200:
> 
> 
> 
> 
> The PSK Packet at 1200 bauds shares the same characteristics as the FSK 
> Packet at 1200 bauds, except some ones:
> 
> 
> 
> 
> * the modulation is a DBPSK one (differential binary phase shift keying), 
> as, for example, in PSK31. DBPSK is better that FSK,
> 
> 
> 
> 
> * bandwidth : about 2000 Hz
> 
> 
> 
> 
> * Pmean/Ppeak: 0.79
> 
> 
> 
> 
> * the lowest S/N is about +6 dB,
> 
> 
> 
> 
> * very high capacity (up to 40 Hz/sec) to follow a satellite drift (using 
> the Cat system of the transceiver).
> 
> This mode is used for satellite (as LUSAT LO-19 for example) transmissions 
> in UHF (USB). But it could also be used in VHF (FM ) with a better 
> performance than Packet FSK, in Unproto (APRS) or in connected mode.
> 
> 
> 
> 
> Description of the PSK Packet 63 and 250 bauds:
> 
> 
> 
> 
> The modulation is the same as BPSK1200 with a different speed.
> 
> 
> 
> 
> The BPSK Packet at 250 bauds has a bandwidth of about 500 Hz and a lowest 
> S/N of about -2 dB whereas the BPSK Packet at 63 bauds (62.5 in fact) has a 
> bandwidth of about 160 Hz and a lowest S/N of about -8 dB.
> 
> 
> 
> 
> 
> 
> 
> 
> - Original Message - 
> From: "Ian Wade G3NRW" 
> To: 
> Sent: Thursday, August 27, 2009 6:38 AM
> Subject: Re: [digitalradio] PSK-PACKET anyone?
> 
> 
> > From: kt4w...@...
> > Date: Wed, 26 Aug 2009   Time: 20:57:35
> >
> >>Anyone up for some PSK-PACKET??  63b
> >>
> >>on 10.141.5   1650hz
> >>21:00 Easttime
> >>
> >>Trip - KT4WO
> >>
> >
> > Trip,
> >
> > What is PSK-PACKET 63b?
> >
> > -- 
> > 73
> > Ian, G3NRW
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 
> >
> > Announce your digital presence via our Interactive Sked Pages at
> > http://www.obriensweb.com/sked
> >
> > Recommended digital mode software:  Winwarbler, FLDIGI, DM780, or Multipsk
> > Logging Software:  DXKeeper or Ham Radio Deluxe.
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>




[digitalradio] Re: P25 or D-Star Software

2008-01-30 Thread mikenetbot
I stand corrected! The software came out yesterday, and it is now possible to 
demodulate D-
Star with a soundcard. If you have the DVSI dongle, you'll be able to recover 
audio. Amazing!

http://groups.yahoo.com/group/dstarsoftware/message/1







[digitalradio] Re: P25 or D-Star Software

2008-01-30 Thread mikenetbot

--- In digitalradio@yahoogroups.com, "mikenetbot" <[EMAIL PROTECTED]>
wrote:
>
> Currently, no. The modem part of P25 and D-Star(in the C4FM mode)
aren't too
> challenging, so those should be able to be done in software(although
P25 is known to
> need a CLEAN discriminator tap on receive, something many scanner
users realized they
> didn't have when trying to decode P25 trunking data). The hard part is
the vocoder.
> Actually getting audio in and out of the datastream requires licensing
a proprietary
> codec(VERY expensive, some have claimed that the price of P25
equipment is dominated
> by the vocoder license), or using a proprietary IC. P25 and D-Star use
similar vocoders(in
> fact, those in the know have suggested that the same IC may be able to
handle both
> systems, even though the literature doesn't mention it). Recently, a
DVSI vocoder dongle
> that interfaces the vocoder IC to a PC has become available, so it's
likely this problem will
> be solved soon. If it is interfaced with some modem software, a
software solution will
> likely be possible.
>
> Check out the vocoder dongle here:
> http://www.moetronix.com/dvdongle/
>
>
> --- In digitalradio@yahoogroups.com, "Gmail - Home" sparcnz@ wrote:
> >
> > Hi All,
> >
> > Know this may be a stupid question, but going to ask anyway.
> >
> > The two digital modes for voice are P25 and D-Star?
> > These a built into the radio, so is there any computer software that
allows one to use
> the mode?
> >
> > Thanks
> >
> > Kevin, ZL1KFM.
> >
> > Get Skype and call me for free.
> >
>




[digitalradio] Re: P25 or D-Star Software

2008-01-30 Thread mikenetbot
Currently, no. The modem part of P25 and D-Star(in the C4FM mode) aren't too 
challenging, so those should be able to be done in software(although P25 is 
known to 
need a CLEAN discriminator tap on receive, something many scanner users 
realized they 
didn't have when trying to decode P25 trunking data). The hard part is the 
vocoder. 
Actually getting audio in and out of the datastream requires licensing a 
proprietary 
codec(VERY expensive, some have claimed that the price of P25 equipment is 
dominated 
by the vocoder license), or using a proprietary IC. P25 and D-Star use similar 
vocoders(in 
fact, those in the know have suggested that the same IC may be able to handle 
both 
systems, even though the literature doesn't mention it). Recently, a DVSI 
vocoder dongle 
that interfaces the vocoder IC to a PC has become available, so it's likely 
this problem will 
be solved soon. If it is interfaced with some modem software, a software 
solution will 
likely be possible. 

Check out the vocoder dongle here:
http://www.moetronix.com/dvdongle/


--- In digitalradio@yahoogroups.com, "Gmail - Home" <[EMAIL PROTECTED]> wrote:
>
> Hi All,
> 
> Know this may be a stupid question, but going to ask anyway.
> 
> The two digital modes for voice are P25 and D-Star?
> These a built into the radio, so is there any computer software that allows 
> one to use 
the mode?
> 
> Thanks
> 
> Kevin, ZL1KFM.
>  
> Get Skype and call me for free.
>





[digitalradio] Re: Report on RFSM2400 vs. OFDM

2008-01-26 Thread mikenetbot
Sorry about the line breaks...note to self, don't trust the post preview 
function. 

What I forgot to mention here is that when the adaptive equalizer models the 
channel, we 
can use that information for more than just equalizing the channel. Most 
current ARQ 
modes make a decision if the channel is good or bad and adjust their modulation 
in a 1-
dimensional manner(good->up, bad->down). If we observe the channel model from 
the 
adaptive equalizer, we can decide how much multipath, noise, fading, selective 
fading, etc 
the channel has. We can then select a modulation that is optimal along each of 
those 
dimensions. I don't know how much of advantage this is over the 1-dimensional 
model(it 
would certainly need much more tuning and testing), but it is interesting. If 
nothing else, 
we could build one killer propagation analyzer into the receiver. 

> So I'm not sure what we could achieve if we willy nilly started to strap 
> adaptive 
equalizers 
> to PTMs. The PTMs may have to be modified to transmit a training signal, so 
> the 
receivers 
> have something definite(and quick!) to model with, rather than a slow 
> adaptive 
equalizer 
> that simply guesses at the received signal. On the other hand, PTMs tend to 
> naturally be 
> far more multipath tolerant, so it's likely we'd have to dedicate less of the 
> transmitted 
> signal energy to the training signal. What's ideal needs some simulation and 
> real over 
the 
> air testing. Heck, we should let a computer search for the right combination 
> of baud, 
> tones, and power dedicated to training data over a wide variety of 
> conditions. Pick a 
small 
> set of winners for varying band conditions, and some synchronous(but slow 
> enough for 
PC 
> s) ARQ, and bam, you got yourself a data mode :).





[digitalradio] Re: Report on RFSM2400 vs. OFDM

2008-01-26 Thread mikenetbot
When I first started poking around, I found a simple comparison paper at 
http://ieeexplore.ieee.org/iel2/672/6329/00247152.pdf . It appears to require 
an IEEE 
membership, or a university internet connection(I'm VPNed into my uni right 
now). The 
bottom of each page does say "U. S. Government work not protected by U. S. 
copyright." 
I've hated not being able to access academic papers in the past, so I'm half 
tempted to just 
observe the copyright notice and post it here. 

The problem with that comparison, and in fact many real world tests is the 
single tone 
modem(STM) ends up using adaptive equalization(the STM wouldn't work at such a 
high 
rate without it), while the parallel tone modem(PTM) doesn't. Adaptive 
equalization is the 
"secret sauce" of high speed STMs. It's what gives them their multipath 
handling ability. 
They basically model the transmission channel, find the inverse transformation, 
and de-
spread the multipath laden signal to form a clean one. In such tests, the STM 
seems to 
come out on top for anything but very local (<50km) ground paths.

PTMs inherently have multipath tolerance due to their MUCH lower baud rates. 
But there's 
nothing that says you can't strap an adaptive equalizer onto a PTM. You'd get 
natural 
multipath tolerance, along with whatever multipath correction needed to be 
performed. 
Most current PTM modems ignore multipath all together, and late signal is lost 
at best and 
causes intersymbol interference at worst. Adding an adaptive equalizer would 
allow PTMs 
to recover this late signal energy along with further reducing ISI. So we'd 
have the secret 
sauce adaptive equalizer, along with natural multipath tolerance, instead of 
just one or the 
other.

It appears that the ham OFDM modes DO include adaptive equalizers(at least, 
WINDRM 
does). I'm not that familiar with DRM, so I'm not sure how much of the 
transmitted signal 
is dedicated to training data(if any at all). Most STMs dedicate a large 
portion of the 
transmitted signal to keeping the receiver's equalizer up to date. Other modes 
that weren't 
designed for adaptive equalization simply use the FEC of the transmitted signal 
to guess 
at the actual transmitted signal, which is then used to train the equalizer. 
Here in the US, 
the ATSC digital television standard uses extremely simple 
modulation(8VSB)...if you sent 
an analog TV transmitter an 8-level voltage signal with a little filtering, 
you'd have an 8VSB 
transmitter. The first generation receivers were horrible with multipath 
handling, but as 
time went on, adaptive equalizer chipsets got better and better and were 
"strapped on" to 
the standard. I have a little HD receiver for my laptop with a fairly recent 
chipset/equalizer. I can receive a perfect copy of the signal in a metal-walled 
narrow 
dorm room(structurally similar to a prison cell, although far more pleasant). 
Yet if 
someone walks around the room, the signal will drop completely. For all I can 
tell, the 
signal got stronger as the person moved, but the equalizer has to sit there for 
2-3 
seconds trying to retrain itself. And sure enough, 2-3 seconds later, I'm back 
to perfect 
copy again. 

So I'm not sure what we could achieve if we willy nilly started to strap 
adaptive equalizers 
to PTMs. The PTMs may have to be modified to transmit a training signal, so the 
receivers 
have something definite(and quick!) to model with, rather than a slow adaptive 
equalizer 
that simply guesses at the received signal. On the other hand, PTMs tend to 
naturally be 
far more multipath tolerant, so it's likely we'd have to dedicate less of the 
transmitted 
signal energy to the training signal. What's ideal needs some simulation and 
real over the 
air testing. Heck, we should let a computer search for the right combination of 
baud, 
tones, and power dedicated to training data over a wide variety of conditions. 
Pick a small 
set of winners for varying band conditions, and some synchronous(but slow 
enough for PC 
s) ARQ, and bam, you got yourself a data mode :).

Mike
KF6EYU

--- In digitalradio@yahoogroups.com, Rick <[EMAIL PROTECTED]> wrote:
> The question becomes: if you had two modems, one using single tone high 
> baud rate vs. one using multi tone OFDM, which one would perform the 
> best in varying conditions.
> 
> Various documents on the internet suggest that there is not much 
> difference, but there is at least one that does show a difference with 
> computer simulations in favor of the multi tone modems. I tend to 
> discount computer simulations as not adequate and prefer the real world 
> under many different conditions that gives you a more accurate practical 
> feel for what can and can not be done. That same document, done as a PhD 
> paper, admitted that some waveforms that worked well on computer 
> simulation, actually did not work at all in an actual real world test.