Protocol 2 transmit questions

FIRMWARE TOPICS ONLY--non-firmware topics will be MOVED
Forum rules
Until such time as the New Protocol firmware goes into general release, all discussion will be concentrated here.
AB1HL
Posts: 4
Joined: Fri Mar 19, 2021 9:12 am

Protocol 2 transmit questions

Postby AB1HL » Fri Mar 19, 2021 10:58 am

I'm writing software to drive an ANAN-100D using Protocol 2, and I
have some questions about how the software should manage the radio
while transmitting.

To transmit, software must set up the Alex LPF and antenna relays, set
the drive level, set the PTT flag, set the DUC frequency, and send I/Q
samples to the DUC. Are there sequencing requirements, or can all the
setup occur in the same High Priority packet? Does the software need
to delay between some of these steps, e.g. pause between changing Alex
relays and setting the PTT flag?

Similarly, are there sequencing/timing requirements when ceasing
transmission? Will anything go wrong if software clears the PTT flag
but there are still I/Q samples in the FIFO feeding the DUC?

What is the effect of the PTT flag in byte 4 of the High Priority Data
Packet? I think it must control the T/R relays; does it also enable
the PA?

What happens if the FIFO feeding the DUC runs dry? Does the DUC
continue to generate a signal of some kind?

Does the radio hardware/firmware automatically reduce power if the
SWR is high enough to cause damage to the PA?

Thank you,
Robert AB1HL
User avatar
w-u-2-o
Posts: 5540
Joined: Fri Mar 10, 2017 1:47 pm

Re: Protocol 2 transmit questions

Postby w-u-2-o » Fri Mar 19, 2021 1:39 pm

I'm not a developer, so my answers are based on general knowledge of the architecture, not the actual code.

Sequencing is very important in TX to RX and RX to TX transitions. Many things must be accomplished before the DAC starts to drive RF output and many things must wait for RF output drive to stop. You can get a top level view of the sort of sequencing that must be considered by looking at the Setup > General > Options > Options-1 page in Thetis. There are also hard coded minimum delays for some of those actions in the Thetis code.

You can use Thetis source code, and also piHPSDR and linHPSDR source code, as a guide to your development. You might even choose to reuse some of that code in accordance with the relevant open source licensing.

As for buffer content, it is incredibly important that buffer content be synchronized with RF transmissions. Otherwise one might hear dead air or, worse, a noise burst on the head or tail ends of the transmission. Flex made a bad mistake about that on early versions of their iOS client. Every transmission was prepended by a noise burst of bad data. Keeping latency (delay) low from mic to antenna and antenna to speaker is also important.

73,

Scott
AB1HL
Posts: 4
Joined: Fri Mar 19, 2021 9:12 am

Re: Protocol 2 transmit questions

Postby AB1HL » Fri Mar 19, 2021 4:34 pm

Scott,

Thank you for the info!

Robert
AB1HL
Posts: 4
Joined: Fri Mar 19, 2021 9:12 am

Re: Protocol 2 transmit questions

Postby AB1HL » Sat Mar 20, 2021 9:42 am

Here's the sequence I've ended up using to switch from receive
to transmit:

1. send a high-priority packet with DUC frequency, PTT=0, drive=0,
and the Alex relay LPF/Ant bits.
2. pause 10 ms
3. send PTT=1 drive=0
4. pause 10 ms
5. send PTT=1 drive=xxx
6. immediately followed by I/Q samples

After sending the last I/Q sample packet, my software pauses what I
believe is long enough for the radio to send all the samples. To
switch back to receive:

1. send a high-priority packet with drive=0 (but still PTT=1).
2. pause 10 ms
3. send PTT=0 drive=0
4. pause 10 ms
5. change the Alex relays to the configuration needed for receive.

I don't understand the ANAN-100D well enough to know if this is
correct. When I record the transmission on a separate receiver (tuned
a little low so it can observe the DUC center), the signal seems
complete, and doesn't include anything spurious at the start or end. I
don't know if this sequence treats the ANAN-100D transmit hardware
politely.

I don't know how to send I/Q samples at the rate that the DUC consumes
them, to avoid FIFO over- or under-flow. I see occasional brief damage
in the transmitted signal, probably as a result of a FIFO error. I'm
generating the samples from FT8 software, not from the ANAN-100D
microphone, so there's no natural rate matching.

Robert, AB1HL
User avatar
w-u-2-o
Posts: 5540
Joined: Fri Mar 10, 2017 1:47 pm

Re: Protocol 2 transmit questions

Postby w-u-2-o » Sat Mar 20, 2021 11:00 am

Have you looked at any of the prior art source code to see what it does?
AB1HL
Posts: 4
Joined: Fri Mar 19, 2021 9:12 am

Re: Protocol 2 transmit questions

Postby AB1HL » Sat Mar 20, 2021 1:43 pm

I haven't looked at other software for the HPSDR.
User avatar
w-u-2-o
Posts: 5540
Joined: Fri Mar 10, 2017 1:47 pm

Re: Protocol 2 transmit questions

Postby w-u-2-o » Sat Mar 20, 2021 2:06 pm

Unless you contact one of the dev's directly, reviewing the source code is going to be your best bet for answers.
W4WMT
Posts: 325
Joined: Sun Apr 09, 2017 10:12 pm

Re: Protocol 2 transmit questions

Postby W4WMT » Sun Mar 21, 2021 1:04 am

AB1HL wrote:I don't know how to send I/Q samples at the rate that the DUC consumes
them, to avoid FIFO over- or under-flow. I see occasional brief damage
in the transmitted signal, probably as a result of a FIFO error. I'm
generating the samples from FT8 software, not from the ANAN-100D
microphone, so there's no natural rate matching.


Hi Robert,

Can't offer much advice for FT8. But for voice mode audio generated at the computer, I just sidestep the whole issue by clocking my sound device from the same GPSDO that clocks my ANAN 7000.

To do the same thing for FT8, I'm guessing, you'd have to clock your computer from a GPSDO? That would be a nice trick that I would love to learn :-)

That said, the resampler ringbuffer in the WDSP library can stitch together the two clock domains if the streams are not too jittery. There is a small penalty, however, that results in a tiny transmit off-frequency phenomenon. Stu AB2EZ can fill you in on that interesting rabbit hole :-)

73, Bryan W4WMT
User avatar
w-u-2-o
Posts: 5540
Joined: Fri Mar 10, 2017 1:47 pm

Re: Protocol 2 transmit questions

Postby w-u-2-o » Sun Mar 21, 2021 1:25 am

W4WMT wrote:There is a small penalty, however, that results in a tiny transmit off-frequency phenomenon.

My apologies, Bryan, but that is not a correct statement. This is only true for people who have not identified the correct VAC and resampler settings for their particular PC. Most people do not experience any resampler induced frequency offset.

We only see posts from people having problems, of course, so that tends to make it already that such issues are endemic when they really aren't.

Return to “Protocol 2 Firmware (all radios)”