Re: Has anyone looked into FPGA-based digitalmodes?


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

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

--- In, "Jose A. Amador" <amador@...>

Graham wrote:

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

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

1) Coordination. The necessary codes should be defined. Netting
transmissions is not trivial, calibration issues are important and
all radios are calibrated equally. A heavy task for CAT, indeed. I
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

PSK31 is not suitable per se, it is not thought for reliable
but for casual keyboarding. Emphasis is on quick responsiveness,
features that increase reliability of transfers also increase
which is felt as undesirable by many keyboarders. Count me in, I
differently if I want to chat with few erroneous characters that do
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
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
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
better, with Z-modem style transfers that resume the file transfer
the link is cut. That also reduces the spectral footprint.

If you views the system on a waterfall display, you would see,
looked like random vary length , short psk31 (type) signals
appearing simulations'ly with in the system band with on say
channels with the odd collision and extended gaps …. Depending
usage why not start to double up on the cannel usage to give a
function under good conditions
A waterfall would be a good thing. It was particularly hard to net
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
than solutions. That is my personal perception.

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

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

This is not without problems. Bad or uncoordinated parameters,
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
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
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,
would love to see a better, open source, low cost mousetrap
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
among other aspects. Adaptive equalization might be used
in a modem. Maybe some good ideas could be taken from Q15X25, with
of course, because it also left a not satisfied wish list.

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


Jose, CO2JA

Join to automatically receive all group messages.