Hi Art,

You might read the discussion here:

http://forums.wugnet.com/msvcr80-dll-missing-NET-ftopict445120.html

Be sure to read it all the way to the end.

73 Dave KB4YZ

wb4mnk wrote:

>When I click on the sound card TX volume to make the TX adjustment I
>get an error which ask for the MSVCR80.DLL. Where do I find this DLL
>and How do I install it? I am using Windows XP. Thanks in advance.
>
>73
>Art
>WB4MNK
>
>

Hi Dave and the group, Well Dave we read all the way to the end and the only
thing I got out of my reading was that the file might be on my computer. I
am just amazed that my computer still has the file on the hard drive and
HamPal can not find it. Now what do I do to make HamPal find this file ?

73
Art
WB4MNK
----- Original Message -----
From: "Dave Jones" <djones@...>
To: <digsstv@yahoogroups.com>
Sent: Monday, May 01, 2006 4:45 AM
Subject: Re: [digsstv] New To HamPal


> Hi Art,
>
> You might read the discussion here:
>
> http://forums.wugnet.com/msvcr80-dll-missing-NET-ftopict445120.html
>
> Be sure to read it all the way to the end.
>
> 73 Dave KB4YZ
>
> wb4mnk wrote:
>
>>When I click on the sound card TX volume to make the TX adjustment I
>>get an error which ask for the MSVCR80.DLL. Where do I find this DLL
>>and How do I install it? I am using Windows XP. Thanks in advance.
>>
>>73
>>Art
>>WB4MNK
>>
>>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.5.1/328 - Release Date: 5/1/2006
>
>

Hi Dave and the group, Well Dave we read all the way to the end and the only thing I got out of my reading was that the file might be on my computer. I am just amazed that my computer still has the file on the hard drive and HamPal can not find it. Now what do I do to make HamPal find this file ?
73
Art
WB4MNK
----- Original Message ----- From: "Dave Jones" <djones@...>
To: <digsstv@yahoogroups.com>
Sent: Monday, May 01, 2006 4:45 AM
Subject: Re: [digsstv] New To HamPal

Hi Art,
You might read the discussion here:
http://forums.wugnet.com/msvcr80-dll-missing-NET-ftopict445120.html
Be sure to read it all the way to the end.
73 Dave KB4YZ
wb4mnk wrote:

When I click on the sound card TX volume to make the TX adjustment I
get an error which ask for the MSVCR80.DLL. Where do I find this DLL
and How do I install it? I am using Windows XP. Thanks in advance.
73
Art
WB4MNK

Yahoo! Groups Links
-- No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.5.1/328 - Release Date: 5/1/2006

Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/digsstv/
<*> To unsubscribe from this group, send an email to:
digsstv-unsubscribe@yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Hello:

Can someone help me in understanding how to do this?
Thanks !
Bob
W1CNY

Hi Bob,

HamPAL includes a new feature for creating a wave file that sends text
in the waterfall. For this feature to operate, HamPAL requires
Irfanview. The path to Irfanview must be properly selected in the
Setup.

See:
http://www.tima.com/~djones/newHamPAL.txt

73 Dave KB4YZ

w1cny wrote:

>Hello:
>
>Can someone help me in understanding how to do this?
>Thanks !
>Bob
>W1CNY
>
>
>

Hi Art,

Windows Defender will generate error messages about the file,
"MSVCR80.DLL".  Removing Windows Defender solves the problem.

73 Dave KB4YZ


>>>
>>>wb4mnk wrote:
>>>
>>>
>>>
>>>>When I click on the sound card TX volume to make the TX adjustment I
>>>>get an error which ask for the MSVCR80.DLL. Where do I find this DLL
>>>>and How do I install it? I am using Windows XP. Thanks in advance.
>>>>
>>>>73
>>>>Art
>>>>WB4MNK
>>>>

Hi Dave, Thank you for the information. I would have never found that
problem.

73
Art
WB4MNK

Dave Jones wrote:
> Hi Art,
>
> Windows Defender will generate error messages about the file,
> "MSVCR80.DLL".  Removing Windows Defender solves the problem.
>
> 73 Dave KB4YZ
>
>
>
>>>> wb4mnk wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> When I click on the sound card TX volume to make the TX adjustment I
>>>>> get an error which ask for the MSVCR80.DLL. Where do I find this DLL
>>>>> and How do I install it? I am using Windows XP. Thanks in advance.
>>>>>
>>>>> 73
>>>>> Art
>>>>> WB4MNK
>>>>>
>>>>>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>

anyone got some insight in what be in store for HAMPAL for 2007 ?

david/wd4kpd

We seem to have fixed this problem.
The poor end to end frequency response was the cause.
Inserting a undervalued coupling capacitor in series with the
transmitter input helped level the response.
We are now getting sync ups every time.
Using the spectrum display in WINDRM gave us the best indication of
the poor response.
HAMPAL is nice to use but does not have the diagnostic ov WINDRM.

Bruce VK4EHT

--- In digsstv@yahoogroups.com, "static5x9" <roverk9@...> wrote:
>
> I am using HAMPAL mainly in a small local group on VHF FM.
> However I am intermittenly getting no Tsync on some contacts and
thus
> nothing further recovered.
> Trying a few times without changing anything, eventually all the
sync
> indicators light up and signal quality is 90% or better so the RF
path
> is good and the modulation depth is pretty right.
> Upgrading my soundcard driver seemed to improve things but has not
> eliminated the problem.
> There are 4 of us in the local group and the problem shows mostly
> between myself and one other station. However that station and
myself
> have no problems with the other 2 stations.
>
> Has anyone experienced this or does anyone know what may be
happening?
>
> Bruce VK4EHT
>

I cant run HamPal without this error cant find library MSVCR80.DLL
Any ideas?  I run Norton here if that matters??

Larry WB9F

I keep getting library MSVCR80.dll error anybody help?

Larry WB9F

I am using a Signalink 1+ interface with mmsstv and it works fine.
However when I try it with Hampal I can receive fine but I can not get
it to transmit....Please help I bekieve I have tried all settings.

Hi Larry,

Windows Defender will generate error messages about the file,
"MSVCR80.DLL".  Removing Windows Defender solves the problem.

73 Dave KB4YZ

LARRY wrote:

>I cant run HamPal without this error cant find library MSVCR80.DLL
>Any ideas?  I run Norton here if that matters??
>
>Larry WB9F
>
>
>

----- Original Message -----

From: Dave Jones

To: digsstv@yahoogroups.com

Sent: Friday, June 23, 2006 11:15 PM

Subject: Re: [digsstv] MSVCR80.DLL

Hi Larry,

Windows Defender will generate error messages about the file,
"MSVCR80.DLL". Removing Windows Defender solves the problem.

73 Dave KB4YZ

LARRY wrote:

>I cant run HamPal without this error cant find library MSVCR80.DLL
>Any ideas? I run Norton here if that matters??
>
>Larry WB9F
>
>
>

Rick,

Check and compare com port settings, make HamPal the same as MMSSTV,
under Option, MMSSTV Set Up MMSSTV (O), TX tab com port should show
PTT there.

HamPal, Setup, Select PTT COMMPORT, use the same setings as MMSSTV,
should work.  Remember though you can only run one SSTV or digital
sound card software at the same time.

HTH,

Jerry

--- In digsstv@yahoogroups.com, "Rick Barth" <k9rvb@...> wrote:
>
> I am using a Signalink 1+ interface with mmsstv and it works fine.
> However when I try it with Hampal I can receive fine but I can not get
> it to transmit....Please help I bekieve I have tried all settings.
>

Hi All

I am looking for a interface cable from a sound Card to the ICom
706MK2G

Thank's
ZS6ROY

73's

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.

Hi Chris,

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.

Andy






On Mon, 24 Jul 2006 05:38:55 -0000
"Chris Long" <lichtsprecher@...> wrote:

> 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.
>
>
>
>
>
>
>
>

Yeah thanks Andy...

But the 18 minutes would accommodate six DIFFERENT images via analogue
- the 18 minutes that I'm talking about was needed to send one SINGLE
image around a group with HamPal. That's what I mean by cumbersome,
but I'm sure things will change. Frankly, they HAVE to!

I can't help but feel that this BSR return file thing will HAVE to
eventually be superceded, either by more sophisticated error
correction sent with the initial picture transmission file or by error
correction specifically tailored to the individual propagation
characteristics of particular hf bands or particular diunal or sunspot
cycle times.

It has consistently fascinated me that multipath via the ionosphere
seems to minimise at or near the MUF. As one goes down in frequency to
40 and 80 metres, the multipathing seems to progressively get worse -
but quite oddly, on 160 metres things seem to be much better. Of
course during the daytime the groudwave transmissions appear to be as
good as 2 metres - but even on skywave at night, the fades are so very
much slower than 80 or 40 that you can often get a complete pic
through before the fade cycle bottoms out. The band is underutilised
in Australia - and I can't help but think that it might see more use
for SSTV.

Interestingly, a British group in 2002 actually constructed a
purpose-built VESTIGIAL sideband transmitter working on 15 metres.
With this, they managed to get amplitude-modulated video through to
America with minimal phase shift over an 8 KHz bandewidth (and that's
the maximum legal width allowed in Australia and Britain - not 6 KHz
as some assume). With all that bandwidth to play with, the group
managed to get MOVING analogue SSTV/NBTV across the Atlantic in real
time - 32 lines, 10 fps. Although the reasons for that test were
predominantly historical - they were transmitting SCANNING DISC TV on
the 75th anniversary of the first successful TransAtlantic test by
John Logie Baird - the usage of vestigial sideband was a fascinating
demonstration of the recovery of phase info via a locked (or
vestigial) carrier. Video signals cannot normally be transmitted on
single sideband without the phase reference that a carrier - or an
audio subcarrier - provides.

I would have thought that somebody would have picked up that aspect of
their hf vestigial sideband tests in technical terms. The pictures,
incidentally, were surprisingly recognisable and clear - 32 lines
notwithstanding, of course! (I think they used the callsign G2KZ for
those tests - the license originally used for the Baird Company's
tests on 6 MHz in 1927-28).

Anyway, thanks for the feedback, Andy. I look forward to the time when
amateurs run DRM real-time audio instead of this atrocious 300 Hz- 3K
distort-o-matic sideband (I'm a dyed-in-the-wool luddite a.m.
enthusiast, I'm afraid most sideband stations have audio that would
even have made the audio engineers in the days of Edison cylinder
records wince!!)

Best wishes one and all,

Chris Long (Melbourne, Australia).

Hi Chris,

the 18 mins would only provide 6 images if all six stations received good copy
on the first attempt. That's an unlikely situation...:-)

The mode is not really suited to group type transmissions, but for one-to-one it
works well.
The problem with better error correction is that the files get bigger, and take
longer to send.

at frequencies above the MUF the signals tend to punch through the ionsphere and
don't get bounced about, hence the lack of mulipath.

160 might be a good band, here in the UK we are a bit limited on power as it's a
shared band, but if you have the space for good antennas, then 160 is a nice
band.

Vestigial sideband transmission is/were used in comercial systems, for much the
same reasons as you describe, it gives the receiver something to lock onto, and
helps to auto tune the Rx. I've not heard any news about that for quite a few
years now so it prob was not much of a success.

As for the bandwidth, there is NO restriction in the UK license. Providing the
signal stays within the band it's OK. However one of the notes to the license
state:

The bandwidths of emissions should be such as to ensure the most efficient
utilisation of the spectrum; in general this requires that bandwidths be kept at
the lowest values which technology and the nature of the service permit. Where
bandwidth-expansion techniques are used, the minimum spectral power density
consistent with efficient spectrum utilisation should be employed.



Before the days of computers and colour sstv we used to send B/W frams of
128x128 pixels with 8 or 16 grey levels. Frames took 7 secs to send. That's
equiv. to  2kbyte in size, and another 1K for level info making a total of about
3kb. Compress that frame, for sending and you could easily send it over a low
bandwidth link, especially if you started using the 'clever' videophone systems
of only transmitting the differences. So I'm not in the least bit surprised that
the 32line / 10fps trial worked.

There's a lot of things that can be done especially nowdays with the computer
systems. SSTV in the past required 5FP7 type tubes (long persistance tubes)
flying spot scanners etc...

one more-or-less local was persuaded to stick his face in the scanner... the
resulting picture was fairly good, execpt that it looked as if it was taken with
a fisheye lens close up. His nose got rather distorted.

All such equipment can now be done away with and replaced with the PC.

With the poor audio on sideband - unfortuntally that's mainly the fault of
speech processors and people who simply don't know what they sound like. A well
modulated sideband signal, should be as good as a telephone call really (band
conditions aside)

It's particually bad when the never ending contests are in full swing. Loads of
high power stations all over processing like mad.

Andy








On Fri, 28 Jul 2006 09:34:33 -0000
"Chris Long" <lichtsprecher@...> wrote:

> Yeah thanks Andy...
>
> But the 18 minutes would accommodate six DIFFERENT images via analogue
> - the 18 minutes that I'm talking about was needed to send one SINGLE
> image around a group with HamPal. That's what I mean by cumbersome,
> but I'm sure things will change. Frankly, they HAVE to!
>
> I can't help but feel that this BSR return file thing will HAVE to
> eventually be superceded, either by more sophisticated error
> correction sent with the initial picture transmission file or by error
> correction specifically tailored to the individual propagation
> characteristics of particular hf bands or particular diunal or sunspot
> cycle times.
>
> It has consistently fascinated me that multipath via the ionosphere
> seems to minimise at or near the MUF. As one goes down in frequency to
> 40 and 80 metres, the multipathing seems to progressively get worse -
> but quite oddly, on 160 metres things seem to be much better. Of
> course during the daytime the groudwave transmissions appear to be as
> good as 2 metres - but even on skywave at night, the fades are so very
> much slower than 80 or 40 that you can often get a complete pic
> through before the fade cycle bottoms out. The band is underutilised
> in Australia - and I can't help but think that it might see more use
> for SSTV.
>
> Interestingly, a British group in 2002 actually constructed a
> purpose-built VESTIGIAL sideband transmitter working on 15 metres.
> With this, they managed to get amplitude-modulated video through to
> America with minimal phase shift over an 8 KHz bandewidth (and that's
> the maximum legal width allowed in Australia and Britain - not 6 KHz
> as some assume). With all that bandwidth to play with, the group
> managed to get MOVING analogue SSTV/NBTV across the Atlantic in real
> time - 32 lines, 10 fps. Although the reasons for that test were
> predominantly historical - they were transmitting SCANNING DISC TV on
> the 75th anniversary of the first successful TransAtlantic test by
> John Logie Baird - the usage of vestigial sideband was a fascinating
> demonstration of the recovery of phase info via a locked (or
> vestigial) carrier. Video signals cannot normally be transmitted on
> single sideband without the phase reference that a carrier - or an
> audio subcarrier - provides.
>
> I would have thought that somebody would have picked up that aspect of
> their hf vestigial sideband tests in technical terms. The pictures,
> incidentally, were surprisingly recognisable and clear - 32 lines
> notwithstanding, of course! (I think they used the callsign G2KZ for
> those tests - the license originally used for the Baird Company's
> tests on 6 MHz in 1927-28).
>
> Anyway, thanks for the feedback, Andy. I look forward to the time when
> amateurs run DRM real-time audio instead of this atrocious 300 Hz- 3K
> distort-o-matic sideband (I'm a dyed-in-the-wool luddite a.m.
> enthusiast, I'm afraid most sideband stations have audio that would
> even have made the audio engineers in the days of Edison cylinder
> records wince!!)
>
> Best wishes one and all,
>
> Chris Long (Melbourne, Australia).
>
>
>
>
>
>

Hi,
Am working on a project and have need to display out the value from an
oscilloscope. Wanted to know if an oscilloscope has any output channel
or port.

Awaiting response.
-r-

Some do, and have done so for many many years. Normally only on the professional
scopes with the professional price tag.

Some of the more serious hobby scopes have the feature, as do most digital
scopes.
PC based scopes normally have some way to get at the data as well.

The main thing to note is that what you get access to varies scope to scope.
Sometimes you only get the amplitude of a signal, Sometimes you get a guess at
the frequency eyc. but as you can't easily predict all types of wavefore then is
a bit iffy to say the least.

If you can save the screen, which you can do with most digital scopes, then you
might be able to do a bit more work such as curve fitting, limit boxes and so
on.

But at the end of the day is all boils down to what the scope provides.

You can also get DVM's, Function generators, sig gens etc with computer
interfaces of one sort or another.

Andy


On Mon, 31 Jul 2006 18:39:40 -0000
"Ramya" <iamramya_n@...> wrote:

> Hi,
> Am working on a project and have need to display out the value from an
> oscilloscope. Wanted to know if an oscilloscope has any output channel
> or port.
>
> Awaiting response.
> -r-
>
>
>
>
>

Some do, and have done so for many many years. Normally only on the professional scopes with the professional price tag.

Some of the more serious hobby scopes have the feature, as do most digital scopes.
PC based scopes normally have some way to get at the data as well.

The main thing to note is that what you get access to varies scope to scope. Sometimes you only get the amplitude of a signal, Sometimes you get a guess at the frequency eyc. but as you can't easily predict all types of wavefore then is a bit iffy to say the least.

If you can save the screen, which you can do with most digital scopes, then you might be able to do a bit more work such as curve fitting, limit boxes and so on.

But at the end of the day is all boils down to what the scope provides.

You can also get DVM's, Function generators, sig gens etc with computer interfaces of one sort or another.

Andy

On Mon, 31 Jul 2006 18:39:40 -0000
"Ramya" <iamramya_n@yahoo.com> wrote:

> Hi,
> Am working on a project and have need to display out the value from an
> oscilloscope. Wanted to know if an oscilloscope has any output channel
> or port.
>
> Awaiting response.
> -r-
>
>
>
>
>

Images on weekends usually.


http://cosmiclog.msnbc.msn.com/archive/2006/08/17/2213.aspx

Hi,

Your comments here are very interesting and along the lines of what
I have been thinking.

I tried analog SSTV for the first time a few weeks ago.  My first
reaction was, "This is very primitive - someone must be doing this
with more modern digital modulation methods".  I was quite excited
to find the digital SSTV mode implemented in HamPal but after a
couple weeks using it, it appears that it has some serious
shortcomings for HF transmission.  The picture quality is stunning -
but it seems to me to be gross overkill for this purpose.  Also the
file delivery success rates make it useful for only very good
propagation conditions and even then usually requires an error
report and retransmission of missing data which is valid for only
one recipient.  Analog SSTV doesn't delivery picture quality
anywhere close to this but it is possible to get useful quality in
marginal conditions.  The widespread success of PSK31 is due to its
capability to delivery useful text in conditions that are marginal
for even CW.

I work on a project that delivers live audio and video using OFDM
modulation so I know it has the capability for providing substantial
improvements to analog SSTV.  I heard that the author of HamPal lost
his code when a lightning destroyed his HD.  I was wondering if
anyone else is working on variations of the HamPal DRM format using
OFDM modulation to deliver useful quality pictures in marginal HF
conditions?  Better error correction would require larger files to
maintain the same picture quality but reducing picture resolution
would seem to me to be an acceptable sacrifice for more reliable
delivery and a more gradual picture degradation with degraded
propagation conditions.

Ed
WB6YTE

--- In digsstv@yahoogroups.com, Andy Eskelson <andyyahoo@...> wrote:
>
> Hi Chris,
>
> the 18 mins would only provide 6 images if all six stations
received good copy on the first attempt. That's an unlikely
situation...:-)
>
> The mode is not really suited to group type transmissions, but for
one-to-one it works well.
> The problem with better error correction is that the files get
bigger, and take longer to send.
>
> at frequencies above the MUF the signals tend to punch through the
ionsphere and don't get bounced about, hence the lack of mulipath.
>
> 160 might be a good band, here in the UK we are a bit limited on
power as it's a shared band, but if you have the space for good
antennas, then 160 is a nice band.
>
> Vestigial sideband transmission is/were used in comercial systems,
for much the same reasons as you describe, it gives the receiver
something to lock onto, and helps to auto tune the Rx. I've not
heard any news about that for quite a few years now so it prob was
not much of a success.
>
> As for the bandwidth, there is NO restriction in the UK license.
Providing the signal stays within the band it's OK. However one of
the notes to the license state:
>
> The bandwidths of emissions should be such as to ensure the most
efficient utilisation of the spectrum; in general this requires that
bandwidths be kept at the lowest values which technology and the
nature of the service permit. Where bandwidth-expansion techniques
are used, the minimum spectral power density consistent with
efficient spectrum utilisation should be employed.
>
>
>
> Before the days of computers and colour sstv we used to send B/W
frams of 128x128 pixels with 8 or 16 grey levels. Frames took 7 secs
to send. That's equiv. to  2kbyte in size, and another 1K for level
info making a total of about 3kb. Compress that frame, for sending
and you could easily send it over a low bandwidth link, especially
if you started using the 'clever' videophone systems of only
transmitting the differences. So I'm not in the least bit surprised
that the 32line / 10fps trial worked.
>
> There's a lot of things that can be done especially nowdays with
the computer systems. SSTV in the past required 5FP7 type tubes
(long persistance tubes) flying spot scanners etc...
>
> one more-or-less local was persuaded to stick his face in the
scanner... the resulting picture was fairly good, execpt that it
looked as if it was taken with a fisheye lens close up. His nose got
rather distorted.
>
> All such equipment can now be done away with and replaced with the
PC.
>
> With the poor audio on sideband - unfortuntally that's mainly the
fault of speech processors and people who simply don't know what
they sound like. A well modulated sideband signal, should be as good
as a telephone call really (band conditions aside)
>
> It's particually bad when the never ending contests are in full
swing. Loads of high power stations all over processing like mad.
>
> Andy
>
>
>
>
>
>
>
>
> On Fri, 28 Jul 2006 09:34:33 -0000
> "Chris Long" <lichtsprecher@...> wrote:
>
> > Yeah thanks Andy...
> >
> > But the 18 minutes would accommodate six DIFFERENT images via
analogue
> > - the 18 minutes that I'm talking about was needed to send one
SINGLE
> > image around a group with HamPal. That's what I mean by
cumbersome,
> > but I'm sure things will change. Frankly, they HAVE to!
> >
> > I can't help but feel that this BSR return file thing will HAVE
to
> > eventually be superceded, either by more sophisticated error
> > correction sent with the initial picture transmission file or by
error
> > correction specifically tailored to the individual propagation
> > characteristics of particular hf bands or particular diunal or
sunspot
> > cycle times.
> >
> > It has consistently fascinated me that multipath via the
ionosphere
> > seems to minimise at or near the MUF. As one goes down in
frequency to
> > 40 and 80 metres, the multipathing seems to progressively get
worse -
> > but quite oddly, on 160 metres things seem to be much better. Of
> > course during the daytime the groudwave transmissions appear to
be as
> > good as 2 metres - but even on skywave at night, the fades are
so very
> > much slower than 80 or 40 that you can often get a complete pic
> > through before the fade cycle bottoms out. The band is
underutilised
> > in Australia - and I can't help but think that it might see more
use
> > for SSTV.
> >
> > Interestingly, a British group in 2002 actually constructed a
> > purpose-built VESTIGIAL sideband transmitter working on 15
metres.
> > With this, they managed to get amplitude-modulated video through
to
> > America with minimal phase shift over an 8 KHz bandewidth (and
that's
> > the maximum legal width allowed in Australia and Britain - not 6
KHz
> > as some assume). With all that bandwidth to play with, the group
> > managed to get MOVING analogue SSTV/NBTV across the Atlantic in
real
> > time - 32 lines, 10 fps. Although the reasons for that test were
> > predominantly historical - they were transmitting SCANNING DISC
TV on
> > the 75th anniversary of the first successful TransAtlantic test
by
> > John Logie Baird - the usage of vestigial sideband was a
fascinating
> > demonstration of the recovery of phase info via a locked (or
> > vestigial) carrier. Video signals cannot normally be transmitted
on
> > single sideband without the phase reference that a carrier - or
an
> > audio subcarrier - provides.
> >
> > I would have thought that somebody would have picked up that
aspect of
> > their hf vestigial sideband tests in technical terms. The
pictures,
> > incidentally, were surprisingly recognisable and clear - 32 lines
> > notwithstanding, of course! (I think they used the callsign G2KZ
for
> > those tests - the license originally used for the Baird Company's
> > tests on 6 MHz in 1927-28).
> >
> > Anyway, thanks for the feedback, Andy. I look forward to the
time when
> > amateurs run DRM real-time audio instead of this atrocious 300
Hz- 3K
> > distort-o-matic sideband (I'm a dyed-in-the-wool luddite a.m.
> > enthusiast, I'm afraid most sideband stations have audio that
would
> > even have made the audio engineers in the days of Edison cylinder
> > records wince!!)
> >
> > Best wishes one and all,
> >
> > Chris Long (Melbourne, Australia).
> >
> >
> >
> >
> >
> >
>

ISS Amateur Radio Status: August 30, 2006

SpaceCam Status, Active Aug 26
By Miles Mann WF1F,

MAREX-MG News www.marexmg.org

Manned Amateur Radio Experiment

Hi everyone:
The SpaceCam1 Imaging project on the International Space Station is
being operated intermittently on weekends. During his spare time, the
ISS Expedition 13 Commander Pavel Vinogradov has been activating
SpaceCam1 project for few orbits randomly. Due to the crews heavy
work load, we do not have a regulate schedule for the SpaceCam1
project.  The ARISS team is still testing various settings and
monitoring the status of the project.  It may be a few more weeks
before we have a predictable SpaceCam schedule.

Our thanks to the many stations that received and decode the test
images. SpaceCam Images from ISS were received in many countries,
including Russia, United Kingdom, Brazil, Australia and many more.
Below is a link to the SpaceCam home page and list of some of the
images we have received.

www.marexmg.org

Images have been received on the following dates:
July 28, July 30, Aug 13, Aug 14, Aug 15 and Aug 26

To date, I have 9 unique images from ISS and many repeats. Ir you
have any new images; please forward the images to MAREX at:

marexmg@...

During the testing phase the ISS Slow Scan TV system may be
intermittently transmitting on the frequency 145.800 MHZ FM.

For information on how to receive these messages, check out the MAREX
link:
http://www.marexmg.org/fileshtml/howtouseiss.html

Over the next few weeks we maybe receiving images from the
International Space station via Slow Scan TV (SSTV). The MAREX team
will be collecting these images from the amateur Radio and SWL
community and we will post the best.

We would like to collect all images received. However in order to
properly catalog the images we request you use the following image
naming format.
After you receive you images, please rename the images using the
following format, All Lower case letters. I have updated the file
naming format to shorten the file names.

Year 06, Month 07, Day 31,  (UTC time), Call sign,
Short text description, .JPG

Example:

Old format:
20060731z1905wf1fwindowshot.jpg

New format:
0607311905wf1f.jpg

I removed the first two numbers of the year and the "Z" for UTC time.
All dates are assumed to be in UTC dates. The images coming down from
ISS will also have a time stamp embedded into the image. You can also
use these numbers to generate you file names.  If you are a Short
Wave listener and do not have a call sign, just place your Initials
after the time (0607311905abc.jpg)

If we break this down
Year =06
Month = 07
Day = 31
Time = 1905 UTC
Call sign = wf1f
Description (optional) = Windows shot
Image format = jpg

Image Quality
Please do not put any text over lays on the images, Example, do not
put web page or advertisements in the image. Your own call sign and
date are acceptable.

Send all images directly to MAREX at
Marexmg@...

We would also like to know the following information
in your email.

Name or Call sign
Country / State
Receiver
Software decoding tool
Elevation or range of ISS when you decoded the image.

Slide Show Mode:
The MAREX SpaceCam1 software contains a feature called "Slide Show"
mode. It allows the crew to preload a directory full of images that
will be automatically transmitted to Earth. The crew will not need to
keep pushing a button to send images. In theory the system can run
for weeks at a time without crew involvement. The SpaceCam project
will be able to transmit over 200 SSTV images per day (Robot 36
format).

During the next phase of testing may use the frequency 145.800 MHz FM
for the SSTV down link. The Slide Show mode will only be testing the
Down link. The uplink frequency will not be published.

SSTV Decoding Software
http://www.barberdsp.com/

There are many choices in SSTV software, some Free,
others with more features cost a few bucks.
http://www.marexmg.org/fileshtml/sstvlinkpage.html

So have fun, find your best setup and start practicing
how to decode SSTV on 2-meters.

Marexmg Web page
http://www.marexmg.org

ARISS Web page and other great Space projects
http://www.rac.ca/ariss/

73 Miles WF1F MAREX-MG

Until we meet again

DOSVIDANIYA Miles WF1F

Good Day
My name is Jay and the call is N3OW.
What I would like to know is what is the Current Software that is
being used for hf digital sstv.
Or do they all work together?
Thank you
Jay

Hi Jay,

DIGTRX 3.11, HamPAL 09JAN06 and WinDRM are all compatable in the DRM
mode for sending picture files.

73 Dave KB4YZ

Jay wrote:

>Good Day
>My name is Jay and the call is N3OW.
>What I would like to know is what is the Current Software that is
>being used for hf digital sstv.
>Or do they all work together?
>Thank you
>Jay
>
>
>

HAS ANYONE NOTICED THAT THE PROGRAM BOOTS WITH THE CALLSIGN ERROR ALL
THE TIME.

I SET UP V24X AND IT WAS OK FOR ONE DAY..NEXT MORNING IT CAME UP WITH
THE ERROR.  V25X AND V26X ALSO DO THE SAME THING.

NOT IMPORTANT YET, BUT MAYBE IN FUTURE, I WOULD GUESS THAT YOUR
CALLSIGN IS NOT TRANSMITTED IN WATERFALL EITHER.

DAVID/WD4KPD