T/R Switch

5 views
Skip to first unread message

NZ0I

unread,
Dec 8, 2017, 11:39:45 AM12/8/17
to Receiver Development Platform
Turning the fox transmitters into QSK-capable fox transceivers would require devising a T/R switch. Relays are expensive, slow, and prone to fail. My thoughts turned to PIN diodes in pi configuration. Then I did a quick search on DigiKey just to see, and found:


It handles up to 3W. It works from DC to 3 GHz. It is small, requires only some isolation capacitors, and costs only $1.60 in one-piece quantities.

I think it solves the T/R switch problem.

Gerald Boyd

unread,
Dec 8, 2017, 3:52:29 PM12/8/17
to NZ0I, Receiver Development Platform

Another possible way this could work is have the control receiver tune to the homing beacon frequency.

This would allow the homing beacon to block transmissions during the meet unless the organizers want them to originate from that unit.

Operation could be as follows. 
If all transmitters are off the on command could be sent using the homing beacon on the homing beacon frequency and have each on command repeated several times to allow error handling. In this case it could be a global on command. Then the remote transmitters would start the sequence.

If the transmitters are on and organizers want to turn them off the homing beacon could address the off command to each transmitter during the mid cycle ( direct address broadcast) when it should be off. This would prevent issues with the remote receivers being desensitized by the remote transmitter and any slight timing alignment with the cycle. It would take almost a complete cycle to turn off all transmitters doing it this way. Moe would get command off during moi and moi would get commanded off during mos and so on. It would be a walking off sequence.

Doing it this way ( control receiver set to homing beacon) would eliminate the need to try sending between the dots and dahs of the fox and have a fast tx to rx turnaround. 



Sent from my iPad
--
You received this message because you are subscribed to the Google Groups "Receiver Development Platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to receiver-development...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/receiver-development-platform/babccb0f-ea4d-42a6-8415-2cadff0cb774%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Charles Scharlau

unread,
Dec 8, 2017, 4:08:06 PM12/8/17
to Gerald Boyd, Receiver Development Platform
I like that concept Jerry. But it seems that the fox transceivers would still need the T/R switch installed in order for the transmitter and receiver to share the same antenna. So hardware-wise we need the same configuration, whether or not we support QSK. Of course, your idea means that we don't need to worry so much about timing, and having the receivers recover so quickly between code elements. Having the hardware support for transceive will allow us to experiment with various concepts.

On Fri, Dec 8, 2017 at 3:52 PM, Gerald Boyd <wb8...@icloud.com> wrote:

Another possible way this could work is have the control receiver tune to the homing beacon frequency.

This would allow the homing beacon to block transmissions during the meet unless the organizers want them to originate from that unit.

Operation could be as follows. 
If all transmitters are off the on command could be sent using the homing beacon on the homing beacon frequency and have each on command repeated several times to allow error handling. In this case it could be a global on command. Then the remote transmitters would start the sequence.

If the transmitters are on and organizers want to turn them off the homing beacon could address the off command to each transmitter during the mid cycle ( direct address broadcast) when it should be off. This would prevent issues with the remote receivers being desensitized by the remote transmitter and any slight timing alignment with the cycle. It would take almost a complete cycle to turn off all transmitters doing it this way. Moe would get command off during moi and moi would get commanded off during mos and so on. It would be a walking off sequence.

Doing it this way ( control receiver set to homing beacon) would eliminate the need to try sending between the dots and dahs of the fox and have a fast tx to rx turnaround. 



Sent from my iPad

On Dec 8, 2017, at 9:39 AM, NZ0I <charles....@gmail.com> wrote:

Turning the fox transmitters into QSK-capable fox transceivers would require devising a T/R switch. Relays are expensive, slow, and prone to fail. My thoughts turned to PIN diodes in pi configuration. Then I did a quick search on DigiKey just to see, and found:


It handles up to 3W. It works from DC to 3 GHz. It is small, requires only some isolation capacitors, and costs only $1.60 in one-piece quantities.

I think it solves the T/R switch problem.

--
You received this message because you are subscribed to the Google Groups "Receiver Development Platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to receiver-development-platform+unsub...@googlegroups.com.

Charles Scharlau

unread,
Dec 8, 2017, 5:05:30 PM12/8/17
to Gerald Boyd, Receiver Development Platform
I know I didn't make it clear in my description: but I don't imagine that we will want (or be able) to send strings of digital information to the fox transceivers in the spaces between the code elements. Instead, I was thinking that we need some way (any way) to flag the fox transceivers to stop transmitting and listen for commands. I am quite certain that each fox's receiver will be totally desensitized (deaf) during its own transmissions, and unable to receive any in-band signals while its own transmitter is putting out a signal.

There is also a chance that some foxes will be close enough together that they are deafened by the transmissions of nearby foxes.

If several, or in the worst case all, the foxes' receivers are desensitized by the other foxes' transmissions, then it could be very difficult or impossible to send any messages to them while any of the foxes is on the air.

But if the foxes are capable of hearing signals between code elements (QSK), then you can guarantee that all foxes will be able to receive a sufficiently-long signal burst - a signal burst longer than the longest code element that any fox sends. Even the fox that is currently on the air should be able to detect such a signal (filling in the space between its transmissions) and shut itself off in response.

So with QSK, if you want to get all the foxes' attention, just send a 10-second long (for instance) transmission. In response, all the foxes will go quiet and start listening for commands, even the fox that was actively transmitting. Then the control station (it could be on the homing beacon frequency, or any other frequency all the foxes' receivers are tuned to) would be able to send digital messages to the foxes, and know that they are all listening. The messages could be very slow, and repeated several times, but with no fox transmissions to interfere.

But QSK isn't totally necessary. There are other schemes, and the one you are proposing might be the way to go.




Gerald Boyd

unread,
Dec 8, 2017, 7:25:52 PM12/8/17
to Charles Scharlau, Receiver Development Platform
Charles 
Thanks 
Now it makes more sense.
Especially with the 10 second I want your attention mode.
That’s a good way of doing it.
Jerry

Sent from my iPad

Charles Scharlau

unread,
Dec 8, 2017, 8:21:15 PM12/8/17
to Gerald Boyd, Receiver Development Platform
The 10-second constant signal was just an example, but probably not the best way to signal the foxes to stop transmitting. That scheme would allow a constant carrier, or someone tuning up on frequency to shut down an ARDF competition. I imagine that some signal pattern might be a better approach - perhaps occurring on several different in-band frequencies, since our receivers and transmitters are very frequency agile. But all that will require some thought and experimentation to figure out. 

Charles
Reply all
Reply to author
Forward
0 new messages