I don't use hampal, it does not work on my PC, and I'm not going to upgrade the PC for a while yet...
However I do use digitrx and that works OK.
The DRM mode is very good, it works great on VHF with almost no retransmissions.
There are several things that I find get misused. The system can transmit files, that's what it does anyway, but it's NOT the ideal mode for such operations, packet, ARQ etc is better. However if you treat it as an improved SSTV use small highly compressed images then things do work a lot better.
If you are listening into a QSO, or are part of a group then yes the transmission can take a long time, but the image eventually reaches the other end intact, also with the correct viewer program, you can sometimes see the image building up. The system works much better when there are only 2 stations involved.
It could also be the case that the QAM was set too high, on poor signals setting QAM to 4 helps, I can choose 3 modes, 2 bandwidths, 4, 16, or 64 QAM and long or short interleave. That's plenty of scope for tweaking things.
Quite often I will leave the Rx on the frequencey and just leave it there for a few hours, if I'm lucky I'll get a couple of pics.
HF comms is a bit trial and error at the best of times, and 20 can be just as bad as 80 at times, but remember that many people can put up much better 20m antennas than 80m antennas. 18 mins for 6 stations was 3 mins per station, which is not that different from normal SSTV, execpt that the image will be perfect. 6 mins per station for the longest is still not too bad, the same as sending the analog pic a couple of times. It just seems to be a long time listening on the side. :-)
As for the stability. Yes your drift is too high. A friend has used Digitrx on an old FT220 (I think) and it's ok on that. It's solid state, but with a VFO which I assume is used to phase lock the VXO on the required band. He does need to leave it on for an hour to stab.
You cannot compare analog SSTV signals with this mode, in analog you can accept some noise, a bit of colour shift or whatever. The digi modes are intended to be error/noise free hence the need for a stable Rx.
Sounds like you have a bit of a fight on your hands with the Rx there, might be time to think of other options if you have any.
On Mon, 24 Jul 2006 05:38:55 -0000
"Chris Long" <lichtsprecher@...
> I installed HamPal with a little online phone assistance from Chris
> VK3DNH last week (and many thanks to him for that!). I'm sure that
> this DRM-based comms will be the eventual future of nearly all ham
> communication below 30 MHz, but the system as presently configured
> seems a bit cumbersome to me...
> Any system reliant on return error correction will always have
> drawbacks in group operation, and even moreso for SWL's like myself,
> who have no trouble in using existing analogue SSTV. (perhaps I
> should point out that the naming of 'HamPal' was particularly
> appropriate, as the system is less user-friendly for SWL's who can't
> send return error correction requests! It certainly isn't "SWL-PAL"!
> In spite of the enthusiasm of those using HamPal, and the excellent
> quality of the pics, text and audio files transmitted, group
> operation can be slow. I actually measured (with a stop-watch) the
> time that it took for a .jp2 file to get right around a group of
> about six operators working on 80 metres (about 3.63 MHz on
> Australia's Eastern coastal area most evenings), all sending their
> BSR files back and forth -
> The LEAST time that it took for one medium-sized picture file to get
> around the 80 metre group was 18 minutes.
> The MOST time that it took for one medium-sized picture file to make
> it around the group was 35 minutes.
> This would appear to be the major current problem with HamPal - and
> the conversation of the 80 metre group is almost totally taken up
> with the complexity of getting those pictures around, rather than
> being concerned with the pictures as illustrations for a technical
> conversation. Perhaps that, in itself, is indicative of a problem!
> I can't help but think that the form of the Reed-Solomon redundancy
> coding used will have to be adapted to suit specific conditions on
> different bands. The redundant interleaving (not sure if I have the
> nomenclature correct here, but it's a point worth making) would have
> to be spread further along the time axis to accommodate the static
> crashes on 80 and 160 metres, more than it would on 20 or 15 metres,
> for instance.
> I had no trouble in decoding HamPal .jp2s "first off" by just
> listening and decoding from received files on 20 metres, but that's
> a much rarer occurrence on 80. I also have trouble with receiver
> drift - I use an ancient valve comms receiver, and try as I may, I
> can't get the drift down below about 20 Hz over the 3-odd minutes
> that it takes to send a file. Perhaps I'm pushing that technology
> too far - but it has had no previous trouble with ANALOGUE SSTV -
> and the majority of SSTV activity in this country and in New Zealand
> remains in analogue form. Analogue is basically easier, more
> straightforward and more bullet-proof to poor s/n, therefore I don't
> think that one could say that HamPal has OBSOLETED analogue at this
> time, as some enthusiasts claim.
> Somebody with far more knowledge of DRM coding than I should perhaps
> explain whether I'm making a valid point about the changing of the
> coding to specifically suit the conditions of different hf bands -
> or have I missed some point whereby this can't be done?
> All the best to the group...
> Chris Long, Melbourne, Australia.