Date   
Re: PSK 31 Revival?

Tom DF5JL
 

Hi Andy,

My big request is not to use frequencies that are within the CW segment, such as 7034 kHz, according to IARU region 1 and 2 bandplan. It took years of hard work, many conversations and discussions to move PSK31 from 7035 kHz to 7040 kHz, since then, virtually conflict-free operation of CW and PSK31 is possible in the only 200 kHz wide 40m band in region 1.

Your suggestion would break old wounds again. According to the IARU Region 1 and 2 band plan, digimodes from 7040 to 7050 kHz are provided. We are currently in talks with the region 3. The aim is to harmonize the band plans in the three regions.

73 Tom DF5JL
IARU Region 1, HF Manager




Am 13.09.2018 um 01:13 schrieb Andrew O'Brien:

Remember the early days of psk31 where we had relatively uncrowned band segments and it was rare to lose your operating frequency due to someone else grabbing “your” spot on the dial ? Well , with FT8 seemingly swallowing all digital QSOs, psk31 is sometimes hard to find . There was a time where PSK31 was lauded for its robust performance but that accolade disappeared mostly due to flooded AGC’s from a crowded PSK band . I’m not convinced we need to invent FSQCall or FT8call if we have uncrowded PSK31 segments, “PSKcall” could achieved with regular PSK in Muktilpsk , Winwarbler or FLDIGI .
So, let’s get back to soundcard mode basics and revisit PSK31. 14070 and 7034 to start ? Actually not sure what the best 40m freq for PSK31 is these days .
Andy K3UK.

PSK 31 Revival?

Andrew O'Brien
 

Remember the early days of psk31 where we had relatively uncrowned band segments and it was rare to lose your operating frequency due to someone else grabbing “your” spot on the dial ? Well , with FT8 seemingly swallowing all digital QSOs, psk31 is sometimes hard to find . There was a time where PSK31 was lauded for its robust performance but that accolade disappeared mostly due to flooded AGC’s from a crowded PSK band . I’m not convinced we need to invent FSQCall or FT8call if we have uncrowded PSK31 segments, “PSKcall” could achieved with regular PSK in Muktilpsk , Winwarbler or FLDIGI .
So, let’s get back to soundcard mode basics and revisit PSK31. 14070 and 7034 to start ? Actually not sure what the best 40m freq for PSK31 is these days .

Andy K3UK.

Re: VARA vs. Pactor-III Speed Comparison Plots

Graham
 

Ok James 

That'a a lot  of 'Buck's for a  Bit'  hihi

At the  lower ranges , the  modem has better  s/n and  throughput ,  than  conventional  2 tone rtty 
the concept is quite novel. The lower the  single carrier bit rate , the  lower the  bit error rate , so by 
running at 37.5 baud  , the  errors  per carrier , are minimised , 

The 'out the box'  thinking , is in the  data  processing , the better the  s/n , the  lower the 
error rate ,  so the  higher can be the  ''compression'' , the higher the  ''compression'',  the 
higher the  volume of 'plain text' that  can be  transmitted , 

As the  s/n falls ,  the  more  robust the  data  processing  becomes, ie less ''compressed'' 'so over the  same  link
the  'plain text' transfer slows .. but as the  on-air  rate remains  'low' at  all  transfer rates
issue's round  path  quality/bit errors are minimised 

73-Graham



Re: VARA vs. Pactor-III Speed Comparison Plots

James Clark
 

Hi Graham

Noted and understood and an interesting strategy to maintain the multi carrier protocol at all times. HF conditions seem to have been pretty bad lately so I'll be interested to see how Vara works under them.

VHF? Not a chance I'm afraid, I am always well beyond VHF range - Oz is a *big* country with lots of space :)

>A more challenging  test  would be  Vara and  P4

AT A$2100 for a P4 I'll leave that test to someone else - my P3 bought secondhand for $500 is quite enough for me :)

Re: VARA vs. Pactor-III Speed Comparison Plots

Graham
 
Edited

James . 

One thing that's  missed ,is,  vara maintains  on air presence as  an ofdm  modem,  and remains so, for all  transfer speeds , that is actually  a  design milestone , whereas   other  systems , revert to mmfsk  in an attempt to  maintain throughput in adverse conditions, [ofdm uses  multiple  psk  carriers , mmfsk  is  single  tone] But sacrifice the robustness of the  ofdm  modem,  a real test  is to have  in band  jamming  at the  same  time , 

The low  on air  rate  of  30 baud  per carrier of  vara and  being adaptive to 'channel  dely' , actually is able to facilitate  reliable  multi-hop long range communications at  maximum speed , only  thing that missing are  the  odd  sun-spot's ..Im not sure , what the  distance  record  stands at now, the  system  is  widely deployed , EU<>USA on 7 MHz has been achieved at good  rates  from a  maritime  mobile  station ..point to point  I don't know ?

I think you  find it  works quite  well ,  you can  deploy the  HF version  over  VHF using fm or ssb , may well  give extended range  and  speed , the  fm  version provides  higher maximum  speed , but not the  very low s/n  of the  HF version ..may be worth looking  at  

A more challenging  test  would be  Vara and  P4  

73-Graham
g0nbd


Re: VARA vs. Pactor-III Speed Comparison Plots

James Clark
 

Thanks Graham.

It'll be a couple of months before I can do much field testing but I'll endeavour to do some semi-formal P3 - Vara comparisons.

I suspect it will be like comparing HF antennas; very difficult (next to impossible!) to establish a consistent and repetitive test environment but rather one gets a "feel" for the better antenna over time - hardly good engineering but I can't think of a better way.

New release of MULTIPSK (4.37) (DFM06-09 radiosondes)

Patrick Lindecker
 

New release of MULTIPSK (4.37)

 

Pour les francophones: la version en français de ce message se trouve sur mon site (http://f6cte.free.fr). Il suffit de cliquer sur le lien "Principales modifications (courriel avertissant de la sortie de la nouvelle version)".

 

Hello to all Ham and SWL,

 

The new release of MultiPSK (4.37) is on my Web site (http://f6cte.free.fr).
The mirror site is Earl's, N8KBR: https://www.paazig.net/f6cte/MULTIPSK_setup.exe

The MD5 signature of the downloaded MULTIPSK_setup.exe file to, possibly, check (with WinMD5 for example), that the downloading works without error, is equal to: 8b9669cf7cfda8abb14b53490dc309ee

Multipsk associated to Clock are freeware programs but with functions submitted to a licence (by user key).

 

The main improvement of MULTIPSK 4.37 is the following:

 

DFM06-09 radiosondes decoding

 

The DFM06 radiosonde is in service since 2006 and the DFM09 one since 2011. It equips the weather balloons used in meteorology. It is a small box of 90 g, equiped with sensors, a GPS receiver (for its position) and a transmitter for data transmission, this one being done according to a mode poorly documented. It is possible to monitor these radiosondes up to a range of 600 km, according to the reception equipment, whereas the weather balloons can travel up to 300 km, in general. It has to be noted that the balloons launches are generally done at fixed time. One or two launches are done each day.

 

For Hams and SWL, the DFM06-09 signal (from can be received:

·                     either from the discriminator output of a classical UHF FM receiver via a direct connection to the PC sound card. However, the receiver must have a large reception bandwidth due to the high modulation speed,

·                     or with a SdR receiver (FunCube Dongle, RTL SDR,...) and directly demodulated by Multipsk. It is the most simple solution.

 

The main launch site of balloons with DFM06-09 radiosondes is Beauvechain in Belgium (frequencies from 402.870 to 404.710 MHz).

 

Note: Multipsk decodes the radiosonde position but not the atmospheric measurements (temperature, pressure etc).

 

This mode is available for licencied copies, only (otherwise, the decoding is stopped after 5 minutes).

 

See general specifications further on.

 

 

Other improvements:

·                     Addition of the distance between the radiosonde (M10, RS41, DFM06-09) and the station monitoring.

·                     In HFDL, a bug relative to the weather messages decoding (METAR, SPECIF, TAF) has been fixed.

·                     In SELCAL, improvement of the received callsigns management (in the Combo box).

·                     In MFSK32 and MFSK64, a bug relative to the SSTV pictures decoding has been fixed.

 

 

Note about translation of Multipsk.exe and Clock .exe:  the 4.36 version of Multipsk has been translated to Spanish by Joachin (EA4ZB), from French.

See: http://f6cte.free.fr/Translation_files.htm.

 

73

Patrick

 

Description of the DFM06-09 mode

Baud rate: 2500 symbols/second.

Modulation : FSK. Each binary symbol is based on a double-bit. The coding used is the "(differential) Manchester": a double-bit "10" expresses a "1", a double-bit "01" expresses a "0" and the double-bits "11" and "00" are undetermined.

Reception mode: FM

Bandwidth : about 8 KHz (but about 2 KHz in base band after FM demodulation)

Demodulation : not coherent

Synchronization for bits: automatic using the signal,

Detection code: yes on 32 bits (synchronization block), testing both polarities

Interleaving : yes (on the 528 bits following the 32 bits of the synchronization block)

Correction code: extended Hamming (8,4) (on the 528 bits following the 32 bits of the synchronization block)

 

Scrambling: no

The frame contains 560 bits shared in different blocks:

·                     a block of 32 bits "Synchronization" (01100101011001101010010110101010),

            And after deinterleaving and Hamming decoding:

·                     a block of 28 configuration symbols (containing also temperature, not decoded by Multipsk),

·                     a first block of 52 data symbols (containing time, date, position....),

·                     a second block of 52 data symbols (containing time, date, position....).

 




Avast logo

L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
www.avast.com


Distorted VARA Signals = Slow Throughput

Tony
 

All:

I recently received an email from someone who couldn't figure out why VARA would not shift into high speed. The modem would not exceed 1000 bps regardless of how good the path was.

After connecting to his station, it became apparent that his signal had lots of RF-induced distortion. The problem went away after he installed RF chokes between his rig and PC. Speeds of 3000 to 5000 bps were easy to achieve after that.

It's obviously a good idea to check ones signal for cleanliness no matter what digital mode you're using. I found the best way to do that is with a cheap SDR Dongle. Not a bad idea to re-check things when adding a new PC or a new transceiver to the shack. New cabling with different cable lengths can also be problematic.

Tony -K2MO

FT8CALL new ver.

Steinar LA5VNA
 

Hi all

The next development version of FT8Call is out. There is also a new website:

http://ft8call.info/

LA5VNA Steinar

Re: Olevia

Andrew OBrien
 

What ?


On Sep 2, 2018, at 2:16 PM, Graham <g0nbd@...> wrote:

Why has this not been removed ?

Re: Chat-Mode Path Simulator Tests

Graham
 

Thank's Tony 

Notably  the  modes that  are  providing  the  most  robust  service, are those by, and,  based on the  work  of
 Pawel Jalocha sp9vrc , in MT63 , first OFDM system available for Ham use , and Olivia , first below the noise 'mmfsk' weak signal mode , as well as Contestia, the original work, must be over 20 years old now , I can vividly remember a qso using MT63 on 7 MHz , watching various cw / rtty contacts on the waterfall , making  no difference to the  qso , either way, that was in the late 1980's , these were  and  are  first generation data  systems . 

There exists the opportunity to revisit the work , but perhaps in a more structured , enlightened
perhaps even moderated environment ....  

73-Graham
G0NBD

Re: VARA vs. Pactor-III Speed Comparison Plots

Graham
 

James /  Tony ,

There  are two , well  actually  three versions  of  VARA 

HF  designed  for  2.4 Khz  ssb  channel 
FM designed  for  standard  voice  FM  VHF replacing  1200 baud packet **
FM  high speed ,  designed to  replace the  9600 baud packet **
** VARA modem is  point to  point only,  not  support  AX25L packet , but  will  provide  forwarding 
at much enhanced speeds 

Not advisable to deploy  FM versions  over HF as the  coding  is not as tolerant to frequency 
drift , as HF , ie,  FM modulation  retains the  spectrum  integrity ..modem remains ARQ and  fully adaptive 

Vara was actually  designed  and coded  on a   windows  XP  computer,  as  far as can be  ascertained ,  VARA has no minimum  PC requirements 

Guide lines  would be ,  

As long as the  PC reaches the  minimum requirements  for  windows XP  ,
the  modem  will run .

73 - 
Graham 

Re: VARA vs. Pactor-III Speed Comparison Plots

Tony
 

On 8/24/2018 10:42 PM, James_Clark@... wrote:

Tony: thank you *very* much for all the effort you put into the testing, it is exactly the information I have been looking for.

My pleasure James. It would be interesting to see how the two modems compare during your field tests. We have a large number of RMS stations here in the states so it was easy to test both VARA and Pactor via the same station.

I'd give VARA a try and see how things go with your notebook -- maybe someone on this reflector can verify whether or not VARA will run on an XP machine.

Look forward to hearing from you James.

Tony -K2MO

 






Tony: thank you *very* much for all the effort you put into the testing, it is exactly the information I have been looking for.

I spend a fair bit of time deep in the Australian bush and use Winlink/Pactor 3 frequently and based upon your tests I'll buy a copy of VARA to add to my armoury. Currently we only have one VARA base station in Oz (in Sydney on 40m) but I'm sure others will pop up in due course.

One spec. I have not seen is that for the minimum Windows machine on which to run VARA. As electrical power is often an issue for me I like to use my XP Intel Atom netbook when possible but I suspect it may struggle with VARA?


Re: [multipsk] [digitalradio] Chat-Mode Path Simulator Tests

Tony
 

Finn:

Glad you found the test results interesting. Contestia is caps-only with a reduced character set. However, it does retain the most commonly used symbols. Fewer bits per character make it twice as fast as Olivia given the same configuration.

What's interesting about Contestia is that it can be made to perform as well as Olivia while using half the bandwidth. For example, Contestia 16-250 vs. Olivia 16-500 have essentially the same HF channel performance and typing speed. Same holds true for Contestia 32-500 vs. Olivia 32-1000.

The Contestia modes mentioned are available in FLDIGI's "custom" mode selection shown (see attached). It lets the user define different tone / bandwidth combinations. Olivia has this option as well.

73, Tony -K2MO







Absolutely interesting, and in many cases one are limited to work within a given narrow BW, like 30m in Europe.

What about UTF 8 ?
I do belive that MFSK 16 do deal with full UTF8 char set in addition to small and capital letters.
What a bout Contestia and Olivia 16/500? Do both deal with UTF 8?
I believe Olivia also deals with, but just lowers the speed during the Umlaut characters.
Yes I know Olivia is slow, but incredibly robust.

I did not think RTTY could ever handle UTF8 ,  but do  Contestia? so the only difference is the fixed Captials ?

Finn LA7UM


ROS HF & HamSphere

Graham
 

After spending a little  time , trying to  intercept  stations, showing as part of the  recent  increase in ROS-HF   usage
showing on the  PSK-Reported , from the  home qth and various   web-based  SDR's ..with  no success 

[ using the  ''decode'' function, its possible to  go hunting  for a  particular call  sign 
in the  [ as noted by J ros ] Jungle of signals , afforded by the  CDMA coding layer ]

One of the  web-beacons ,  contained the  text   ' HamSphere '  Ah  not  actually radiating RF !

For those who  subscribe to the  service , a good  opportunity to try the  mode out !
good results may be  obtained via the  web-sdr's , being  self synchronising , web 
delay is not a  problem 

https://en.wikipedia.org/wiki/HamSphere

73-Graham 

Re: Chat-Mode Path Simulator Tests

Tony
 

One question: why in these difficult propagation conditions where
modes with only  500 Hz bandwidth compared? 73-Graham G0NBD
It's a matter of leveling the playing field Graham. The majority of
modems change speed when you increase their bandwidths so you can't do
an apples-to-apples comparison when one mode has a much faster character
rate than the others. The bandwidths of each mode may be the same, but
the character rates may be very different. That's a problem if you're
trying to test modes that fall into a specific character-per-second
range as I did.

Olivia and it's variants are the exception in that they can be
configured to achieve certain speeds regardless of bandwidth so you can
get close to another modes specs. That's done by either decreasing or
increasing the baud rate (number of tones) while leaving the bandwidth
the same.

From a practical point of view, I think a bandwidth of 250 to 500 Hz is
usually sufficient for keyboard chats. The path tests show that it's not
always necessary to increase bandwidth in order to improve throughput if
there's another more robust mode available.

Tony -K2MO

Re: [multipsk] [digitalradio] Chat-Mode Path Simulator Tests

la7um
 

Absolutely interesting, and in many cases one are limited to work within a given narrow BW, like 30m in Europe.

What about UTF 8 ?
I do belive that MFSK 16 do deal with full UTF8 char set in addition to small and capital letters.
What a bout Contestia and Olivia 16/500? Do both deal with UTF 8?
I believe Olivia also deals with, but just lowers the speed during the Umlaut characters.
Yes I know Olivia is slow, but incredibly robust.

I did not think RTTY could ever handle UTF8 ,  but do  Contestia? so the only difference is the fixed Captials ?

Finn LA7UM

Re: [multipsk] [digitalradio] Chat-Mode Path Simulator Tests

Tony
 

On 8/25/2018 6:00 PM, Patrick Lindecker wrote:

Very interesting  Tony,  It seems that Contestia and MFSK16 are the best modes.



Patrick: 

It is interesting to see how each modem performs when restricted to a specific characters-per-second range and limited bandwidth. Levels the playing field.

Thanks,

Tony -K2MO
 

Re: VARA vs. Pactor-III Speed Comparison Plots

James Clark
 

Tony: thank you *very* much for all the effort you put into the testing, it is exactly the information I have been looking for.

I spend a fair bit of time deep in the Australian bush and use Winlink/Pactor 3 frequently and based upon your tests I'll buy a copy of VARA to add to my armoury. Currently we only have one VARA base station in Oz (in Sydney on 40m) but I'm sure others will pop up in due course.

One spec. I have not seen is that for the minimum Windows machine on which to run VARA. As electrical power is often an issue for me I like to use my XP Intel Atom netbook when possible but I suspect it may struggle with VARA?

Re: FT8CALL, The NEWEST HF Digital Mode, Introduction and Demo

Ham Radio
 

I have tested this new mode on 40 and 20 meters and it does indeed “work” There are some very nice features such as the FT8CALL beacon.

The current FT8CALL protocol has no way of detecting lost segments in a multi-segment message.  With propagation paths running about 50% reliability these days, message segments will be lost.

The V4 protocol used in Winlink (V4 has ARQ and adaptive modulation types) works much better than FT8CALL  (in my view).

Time will tell ...


73, Bernie