Re: Has anyone looked into FPGA-based digitalmodes?


Graham
 

OK , It was simply a concept based on current systems , the original
panoramic digipan system capturing all, now expanded to cover rtty
and the Olivia recovery in drm780 , my experience with hf packet
back in the 80's when you could digi all over the place on 10 Mtr's ,
the wspr auto beacon software decoding down in to the noise and the
latest `cw' skimming software that is capturing the call signe ,
operating frequency and posting it to a web server...

As with the above I should think the calibration of a standard ham
ssb set would be good enough to ensure net , as for the
communication protocols .. well who knows …a sort of lynux (compared
to windows) communication system that sits in a small space and
uses the advances in computing power and narrow modulation 'modern
frequency usage' and allows everyone to join in, with the same dial
setting

I think the intelegent use of a band of frequencys would reprensent
progress in 'ham' data transmission ?



--- In digitalradio@yahoogroups.com, "Jose A. Amador" <amador@...>
wrote:


Graham wrote:

****I really do not understand Graham's proposal: a narrow band
spread
spectrum system? I really need some more clarification about
this.***

Ok may be a bit like calling a steam train a iron horse, dose the
same thing but a little differently

Spread spectrum : may not be quite the intended system, more
like a
frequency agile system within a constrained pass band, where data
packet are transmitted, by say psk31 type modulation, on random
channels within the pass band – collision avoidance with multi
users, and short data bursts
Now I see. Frequency hopping spread spectrum.

Those channels are not really random, but pseudo-random. I foresee
two
problems:

1) Coordination. The necessary codes should be defined. Netting
those
transmissions is not trivial, calibration issues are important and
not
all radios are calibrated equally. A heavy task for CAT, indeed. I
am
not sure it can be done well enough, or without special radios.

2) Administrative. It will be hard to convince communications
administrations to let run systems they cannot monitor easily or
reliably.

PSK31 is not suitable per se, it is not thought for reliable
transfers
but for casual keyboarding. Emphasis is on quick responsiveness,
because
features that increase reliability of transfers also increase
latency,
which is felt as undesirable by many keyboarders. Count me in, I
react
differently if I want to chat with few erroneous characters that do
not
obliterate the meaning or if I want to transfer a file reliably.

AX25 : merely as comparison to existing mode's of operation,
some kind of watered down system that would allow routing via
other
stations, mail boxes that sort of thing, ok the data rate wont be
too high, but just a novel system using the pc as a intelligent
modem. could transmit command/route packets and data packets to
keep things short
Actually, it is not only AX.25, but using the BBS Interface
Specification Working Draft 11/28/93

Is there any newer? I have not seen any other, newer or improved.

FBB modified some aspects of it, specially regarding compressed
transfers, but this is the basic protocol as I understand. I also
keep
the FBB protocol docs on a backup CD. The FBB and JNOS sources
could be
a good guide for someone interested in the tiny details. FBB does
it
better, with Z-modem style transfers that resume the file transfer
where
the link is cut. That also reduces the spectral footprint.

If you views the system on a waterfall display, you would see,
what
looked like random vary length , short psk31 (type) signals
appearing simulations'ly with in the system band with on say
fixed
channels with the odd collision and extended gaps …. Depending
on
usage why not start to double up on the cannel usage to give a
fec
function under good conditions
A waterfall would be a good thing. It was particularly hard to net
in,
even with a well calibrated radio without being able to really
watch the
spectrum using a TNC with no tuning indicator.

Summarizing, I believe this is too complex and creates more
problems
than solutions. That is my personal perception.

What I feel is needed is something based on the established
technology
(AX.25, BBS Spec) with a new modem more suitable for HF than the
old
Bell 103 modem.

I see divided opinions, many prefer the shared frequency concept.

This is not without problems. Bad or uncoordinated parameters,
hidden
stations, collisions, all reduce the transfer efficiency. I still
remember that 14095 could be quite messy at times.

I participated on a net where one station was the hub and
clearinghouse,
all had to be coordinated with the net manager, and it worked
rather well.

Something similar to frequency hopping but not exactly so were the
procedures used by the AMTOR/Pactor mailboxes, scanning several
channels
per band, and using one for the entire connection period.

What does this has to do with FPGA based data modes? At the end, we
still need a better HF modem than the Bell 103. One step at a time,
I
would love to see a better, open source, low cost mousetrap
implemented
for reliable transfers.

I feel important to note and take adventage of what strategies are
proven to work, and not reinvent the wheel. Exact bit to bit
compatibility to say, pactor, is not as important as a good robust
modem, negotiable signaling speed and coding adapted to HF
propagation,
among other aspects. Adaptive equalization might be used
advantageously
in a modem. Maybe some good ideas could be taken from Q15X25, with
care,
of course, because it also left a not satisfied wish list.

It is not necessarily as simple as stating such a wish list, but
there
should be some intellectual property modules that actually do some
of
the above, in modules, to simplify the programming tasks ahead.

73,

Jose, CO2JA

Join main@digitalradio.groups.io to automatically receive all group messages.