| |
GM7HUD > PACKET 19.06.07 10:15l 29 Lines 1479 Bytes #999 (0) @ WW
BID : 68084_GB7ESX
Read: OE7HNT GUEST
Subj: Re:FT817/ IC706/ 9k6 experiments
Path: DB0FHN<DB0MRW<DK0WUE<DB0RES<ON0AR<GB7YKS<GB7SYP<GB7ESX
Sent: 070619/0719z 68084@GB7ESX.#31.GBR.EU $:68084_GB7ESX [Witham, Esx]NNA V3.1
Ray Vk2TV writing about FTD's 9k6 stuff said:
>The IF bandwidth is going to be the limiting factor here. What are the
>bandwidth specs for the IF filter like?
IIRC (and it's a long time ago) the BW of a 9k6 FSK signal is about 20kHz
so you need a 25kHz filtered set.
One of the problems you *MAY* encounter with a rig like the 817 is the time
it takes to switch over. This is not just the TXdelay time but what should
be termed the RXdelay: the time for the set to switch back from TX to RX and
for all the PLLs to settle on the RX frequency.
Some of the popular xtal controlled data receivers had extremely fast
recovery times from TX whereas the synthesied sets didn't. Of course some
synthesised sets work great at 9k6. But a problem I do remember was that
having set up some all xtalled equipment, there was a problem using an Icom
IC207 with them. The Icom could monitor the link all day without dropping a
packet but when used to TX and RX it took so much longer to recover that it
used to miss much of the start of TX from the xtalled sets. Setting TX delay
to a bigger value on the xtalled sets helped but it seemed so wrong to
have some radios that could cope with a TX delay of 20ms only to then need
300ms so the modern radio could work with the 15 year old sets! Especially
when (again my memory is failing here) 300ms equates to sending nearly 300
bytes of data!
Of course YMMV but it will be interesting to hear how well the 817 works.
73 de Andy GM7HUD
Read previous mail | Read next mail
| |
