Thread Rating:
  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Short Text Messages
How do we want to send Short Text Messages via M17?

Bonus question: do we need to differentiate between M17 streams and packets? Every packet can be sent as a stream anyway.
We need an option for acknowledgement (retry n times until acked) and the ability to disable acks (e.g. for satellite QSOs).

I think packet can dispense with a LICH as it will be of little use for bursts of data. We can still retain the frame size.

Do we want to mimic the 140-byte SMS limit, or should we just allow arbitrary size, use as many frames as needed, and have either some EOT indicator (Unicode EOT 0x04) or a size indicator in the first frame?
Most other DV systems have a choice of acknowledged and unacknowledged data. M17 should offer the same. Unacknowledged could include GPS data.

If we dispense with the (fragment) LICH, then how do we differentiate frame types without decoding the initial LICH, or even tell if it contains data?
ACK - No ACK option is nice feature.
We may also require ACK for gps messages, so we can use it like a ARTS system of Yaesu in the future.

Bonus answer:
If we are not going to need high speed data, we don't need stream type imho. However, if we are going to try some full duplex qso, automatic rssi report or single frequency repeater technologies, It may save some bits and create a space for us.
If we don't have a stream type, how is the receiving end going to interpret the data? How does it know if it's GPS (what type of GPS?), a picture, or something else? We could do with a content type byte or similar.

In most DV systems, GPS data is unacknowledged. After all there'll be more data in a minute or so. In D-Star, the GPS data is in the form of a long-form APRS packet which makes gatewaying to APRS-IS very easy indeed and allows for the APRS type and text message to be set nicely.
We may use some bits for defining the content. If I am not missing something, we already have some spare bits in the LICH packet.
I am dreaming about TDMA from the beginning. Actually before M17, I was experimenting using codec2. Someday, If we wanted to try single frequency repeater, we need a known and standard length tx times. In stream mode it looks a little bit more difficult to obtain this.
We are discussing short text messages. If we want data (such as APRS), we should discuss that too. But we should keep those separate as they have different requirements. Text, like voice, can suffer a few bit errors and still remain intelligible. Data typically cannot.

We can consider using some of the reserved frame type bits to identify the data type.

Would we want to use different FEC puncturing matrices for data to reduce error rates?

Also, can we require that text messages use UTF-8 encoding?
UTF-8 or UTF-16? :-)
(10-27-2020, 05:02 PM)SP5WWP Wrote: UTF-8 or UTF-16? :-)

If we don't specify it, some joker is going to try to use a Microsoft code page or shift-JIS.

With APRS, there's some messaging issues because new code supports UTF-8 and there are clients that are still stuck in the 1980s.
I'd like people to be able to write in Cyrillic too, so how about UTF-16?

Forum Jump:

Users browsing this thread: 1 Guest(s)