[digitalradio] Re: Test version of Multipsk about ARQ FAE in ALE400
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
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
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
--- 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
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
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
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.