Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Use of the DST field with M17 repeaters
#1
With my M17 Gateway running off the back of the MMDVM Host, I am using that field to control linking and unlinking to reflectors. I follow the same general rules as D-Star with "M17-USA BL" kinking to the M17-USA reflector module B, "       U" for unlinking, "      E" for echo, and "      I" for information, which is currently unimplemented. This is fine so far. However what should be transmitted from the repeater?

Should the repeater map all incoming transmissions to the broadcast address on retransmission? Would this apply to network as well as local RF users? Will M17 radios only be sensitive to the users callsign and the broadcast address, or will they listen promiscuously?

It would be nice to nail this down soon, so that we don't get odd incompatibilities between implementations. Note that the above discussion does not cover what is sent over the network with M17 which is pretty well defined already.
Reply
#2
I will identify the problems I consider to be important and how I intend to tackle them in my version of M17, both the repeater/gateway combination and in my proposed M17 client software.

The problem is not really on the client side. M17 has two callsign fields, source and destination, the source will be the callsign of the person operating the radio, the destination is a little more complex. In my M17 Gateway software, the destination can be used to control the way in which the gateway acts. To this end I will follow D-Star convention with the last letter of the field containing the action to take. L to initiate a reflector link, U to unlink, E for echo testing, and I for information. This does not preclude other letters having meaning. In a point-to-point conversation the destination callsign can either be the target callsign or the broadcast identifier. I expect M17 radios to be promiscuous in receiving transmissions.

My main concern is at the repeater side of the conversation. What do we want the source and destination callsigns to include? And what do we do about the other callsigns/information that we would like to send?

Let us imagine a transmission from a user via a reflector that your local repeater is linked to. There are three pieces of information that it would be good to have available, for informational and potentially legal reasons. Let the reflector user be "G9BF", your local repeater is "GB7ABC", and the reflector being "M17-ABC D". Under these circumstances I would expect the M17 destination callsign to be set to the broadcast value. I would expect the source callsign to be "GB7ABC", since that is the source of the transmission. To use "G9BF" would be incorrect as the source of the RF is not from him, but from the repeater. However what to do with the source callsign (G9BF) and the source reflector (M17-ABC D)? I realise that this information will be available within the audio stream from "G9BF" as he talks, however having it embedded within the transmission in a digital form would be good for display purposes.

What I propose to implement is to expand the use of the META field in the LSF to include this information along with optional GPS, encryption, and text. If we use the current M17 callsign encoding method, we can put both callsigns within the field with some space at the end, this will allow it to be displayed, although at a later time than the other information, but probably within a second or so.

If the repeater is repeating a local transmission without a linked reflector then the reflector information would be set to the broadcast value which isn't a valid value under these circumstances. These finer points can be investigated once we have working client and repeater software which will allow for testing and the tweaking of these ideas.

Jonathan G4KLX
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)