Welcome, Guest
You have to register before you can post on our site.



Search Forums

(Advanced Search)

Forum Statistics
» Members: 259
» Latest member: KD9KCK
» Forum threads: 86
» Forum posts: 595

Full Statistics

Online Users
There are currently 30 online users.
» 0 Member(s) | 29 Guest(s)

Latest Threads
Use of the DST field with...
Forum: Technical
Last Post: G4KLX
06-03-2021, 07:34 PM
» Replies: 1
» Views: 217
M17 Fullrate and Wideband
Forum: General discussion
Last Post: Kooga
05-29-2021, 12:53 AM
» Replies: 0
» Views: 67
Re-use of NONCE space
Forum: Technical
Last Post: tarxvf
05-08-2021, 07:40 PM
» Replies: 11
» Views: 937
USRP2M17 make error
Forum: General discussion
Last Post: G0VGS
05-08-2021, 10:57 AM
» Replies: 0
» Views: 269
new version of mvoice
Forum: General discussion
Last Post: G0VGS
05-07-2021, 11:32 AM
» Replies: 20
» Views: 4,718
Audio quality initial rea...
Forum: General discussion
Last Post: G0VGS
05-05-2021, 06:21 AM
» Replies: 2
» Views: 322
register reflector M17-EA...
Forum: Reflectors
Last Post: on6dp
04-28-2021, 11:17 PM
» Replies: 2
» Views: 1,018
How to turn an old Motoro...
Forum: Technical
Last Post: md
04-26-2021, 10:24 PM
» Replies: 4
» Views: 1,273
USRP2M17 added to MMDVM_C...
Forum: Technical
Last Post: N4IRS
04-11-2021, 02:02 PM
» Replies: 1
» Views: 444
M17 Protocol Proposals
Forum: Technical
Last Post: G4KLX
04-05-2021, 03:53 PM
» Replies: 7
» Views: 720

  M17 Fullrate and Wideband
Posted by: Kooga - 05-29-2021, 12:53 AM - Forum: General discussion - No Replies

Hello! Are there any plans to add the ability to use fullrate codecs? The M17 air interface provides data rates up to 9600 and it would be nice to be able to use of higher rate codecs, by analogy with AMBE Fullrate. It would also be interesting to have a wideband radio interface for operation in the 25 kHz bandwidth, at a rate higher than 9600. In this case, it would be possible to use wideband codecs.

Print this item

  USRP2M17 make error
Posted by: G0VGS - 05-08-2021, 10:57 AM - Forum: General discussion - No Replies

Hi all,
Just starting to explore the USRP2M17 bridge and got as far as 'make'. Unfortunately I get an error.  I have reloaded from git and also tried a 'make clean' but I still get the same error.  I would appreciate any help with resolving it.  I have attached the error.



Print this item

  Audio quality initial reaction
Posted by: G0VGS - 05-04-2021, 01:30 PM - Forum: General discussion - Replies (2)

Hi all,
Newbie alert!

I have set up mvoice on a raspberry pi and also in a VM using Ubuntu.  On both, I find the audio coming back from the echo server rather gravelly.  Is this just the echo server?  I have checked the headset and it appears fine.
It may be that this is the current state and that is fine.  I am just trying to work out if I have done something wrong along the way Smile

73 Ian

Print this item

  Use of the DST field with M17 repeaters
Posted by: G4KLX - 04-19-2021, 10:22 PM - Forum: Technical - Replies (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.

Print this item

  Re-use of NONCE space
Posted by: G4KLX - 04-19-2021, 10:16 PM - Forum: Technical - Replies (11)

Wouldn't it be nice to allow the space occupied by the NONCE to be used for other things as well as encryption data?

In the specification, we have the case that if bits 3..4 of the TYPE are set to 0b00 then there is no encryption, and bits 5..6 which are the encryption subtype will be unused. How about extending this so that when their is no encryption, bits 5..6 are used to describe the contents of the NONCE field, which is no longer a NONCE field. For example bits 5..6 with a value of 0b00 would mean unused, 0b01 would mean text (name, locator, etc), 0b10 could be APRS in MIC-E format, leaving 0b11 free for now. That way we would have extra space for data which will be repeated without taking away any bandwidth from the audio. It would mean that the fragment LSF would need constant decoding since it could have multiple data types, and could also include changed APRS data.

Having this data does not preclude encryption, it just means that the encryption data would be sent slightly less often, but presumably that data wouldn't change during the duration of the transmission anyway. Typically for the initial Link Setup Frame, if encryption is being used, then the NONCE would be used for the encryption data, and the other data would appear un the fragment LSFs during the transmission. If encryption is not being used then the initial Link Setup Frame would contain one of the other data items if used, like the text field.

Print this item

  USRP2M17 added to MMDVM_CM
Posted by: AD8DP - 04-07-2021, 04:43 AM - Forum: Technical - Replies (1)

I added USRP2M17 to my fork of MMDVM_CM.  This allows M17 reflectors to be connected to AllStar nodes, and can also be used with the MMDVM FM mode.  I haven't tested the MMDVM FM mode yet, but if it works the way I expect, I will probably ditch my xxx2PCM utils and use the USRP2xxx utils for stand alone digital radio using MMDVM and an analog radio. USRP2xxx for all other digital modes will follow soon, along with DSTAR2xxx which will make the MMDVM_CM utility collection a fully open source, client and server side cross-moding/transcoding/bridging/connecting solution.



Print this item

  V/D & D/D modes
Posted by: WX9O - 03-31-2021, 05:08 PM - Forum: Technical - Replies (2)

How do we envision streaming data modes being used?

We cannot easily switch modes mid-stream right now because an LSF must be sent when switching modes.

What sort of data do we see being streamed at 1600bps or 3200bps?

Print this item

  Symbol Timing Requirements
Posted by: WX9O - 03-28-2021, 08:44 PM - Forum: Technical - Replies (4)

What are the symbol timing requirements for M17?

Symbol timing requirements do not appear to be specified for D*Star, the only other amateur radio DV mode.  (If you have an authoritative reference for this, please add it below.)

DMR requires 2ppm for mobile stations and 0.5ppm for base stations. https://www.etsi.org/deliver/etsi_ts/102...20201p.pdf , section 10.1.4

P25 requires 10ppm symbol timing accuracy. https://www.viavisolutions.com/en-us/lit...tes-en.pdf (Symbol Clock Error)

NXDN requires 10ppm symbol timing accuracy. https://dl.cdn-anritsu.com/en-au/test-me...L11200.pdf (Modulation Symbol Speed)

In addition to this, we must specify the deviation accuracy requirements and the frequency accuracy requirements for the RF section.

Print this item

  Remove CRC from Audio Payload Frame
Posted by: WX9O - 03-27-2021, 10:31 PM - Forum: Technical - Replies (1)

Hi guys,

I suggested a while ago removing the CRC  from the audio frame in order to reclaim more bits for error correction, changing the puncture table.

I'd like to revisit that.  Today, the CRC provides little value.  I only use it to check whether the end of stream (EOS) bit is valid.  Otherwise it is ignored.  The audio data is passed as is to the Codec2 decoder whether the CRC is valid or not.

Using a 16-bit CRC to protect one bit is not a good use of bits.  Our decoders have to be able to handle an end of stream condition when the EOS bit is incorrect in any event.  The lack of a valid sync word on the next frame has the same effect.

Encryption is the only place where a frame number is meaningful.  When using encryption the decoder can track the frame numbers and can detect a valid frame sequence.

If we drop the CRC, we will be encoding 18 bytes, 144 bits + 4 flush bits into 148 * 2 = 296 bits. This needs to be punctured to 272 with a simple 11/12 puncture matrix. The current puncture matrix is ~ 5/6.

Kind Regards,

Rob Riggs WX9O
Mobilinkd LLC

Print this item

  M17 Protocol Proposals
Posted by: G4KLX - 03-27-2021, 07:19 PM - Forum: Technical - Replies (7)

Now that we have removed the CAN from the FICH and agreed to include a 4-bit CRC. This means that we have one spare bit in each FICH. This leads to the following layout for the FICH:

 0..39 40-bits of full LSF
40..42 A modulo 6 counter (LICH_CNT) for LSF reassembly
43     Reserved (set to 0)
44..47 4-bit CRC

It takes six fragments to get a full LSF. however when there is no encryption, which is common, this is just zero bytes and a waste. It would be better if we could send a shorter LSF and so we could decode the information from less frames when the link setup frame is not decoded. With no encryption the NONCE data can be removed. Therefore only the DST, SRC, TYPE and CRC are needed, that is 128 bits instead of 240. With 128 bits we can send all of the data in four fragments instead of six. The use of this shorter LSF can be indicated by this reserved bit. Leading to:

 0..39 40-bits of full LSF
40..42 A modulo 6 (Long LSF), module 4 (Short LSF), counter (LICH_CNT) for LSF reassembly
43     Type of LSF, 0 = Short, 1 = Long
44..47 4-bit CRC

The long version is the same as we currently have with six fragments. The short version is the LSF without the NONCE. In the short version there are some unused bits in the final fragment, these are ignored and should be set to zero. I have a question, should the CRC in the short LSF be only for the DST, SRC, and TYPE, or should it also include the missing zero filled NONCE? The latter would make life easier for sending this data over the network where the NONCE will always be included.

The 4-bit CRC would use a standard polynomial, and I can give example code for the M17 specification once I have coded it. For efficiency, this CRC would be over the fill 48 bits of the LICH with the space for the CRC being set to zeroes. This would allow for an efficient byte wise implementation of the CRC algorithm.

Jonathan  G4KLX

Print this item