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 26 online users.
» 0 Member(s) | 25 Guest(s)

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

  Distinguishing between frame types and FN
Posted by: G4KLX - 10-16-2020, 03:57 PM - Forum: Technical - Replies (14)

Hi All

When receiving M17 frames, for stream mode there are two frame types, the Link Setup frame and the rest. They are the same length and use the same sync vector. How is it possible to distinguish between them? I can think of a way, but it is computationally expensive and appears sub-optimal. Is there an easier way?

I have an observation: why is there a 16-bit FN field? On a network packet I can understand it, but on RF frames I do not, they cannot appear out of order. I think the FN is used so that it is possible to put the LICH chunks back together if you missed the initial Link Setup frame and perform a late entry, this is what NXDN does for example. However to do this, you only need a counter to five, and an extra pattern or bit to indicate the end of transmission as now, and you save a great number of bits.

For comparison P25 phase I has no header (it has an optional encryption header but that is a different thing) and all incoming transmissions are late entry.

Jonathan  G4KLX

Print this item

Posted by: G4KLX - 10-14-2020, 11:03 AM - Forum: Technical - Replies (1)

Is there anywhere that the bits of the SYNC word are documented?

The specification is pretty clear, but that appears to have been overlooked.

Print this item

  M17 abuse mitigations
Posted by: tarxvf - 10-06-2020, 01:11 PM - Forum: Technical - Replies (4)

There's interest in optional abuse mitigations - some similar to APRS IP gating password schemes or other simple shibboleths, others getting into full-blown key distribution issues.

There's also a need to decide where this mitigation happens - at the network level only, or all the way down into RF.

Print this item

  m17dump - dump your packets to the screen!
Posted by: KC1AWV - 09-25-2020, 06:11 PM - Forum: Technical - Replies (1)

If you want to test the output of your TR-9 like SP5WWP and I do, you can use our m17dump program.

You can find it here:

M17 Git - m17dump

If you find a bug, let us know!

Print this item

  TR-9 BOM update
Posted by: elms - 09-23-2020, 08:36 PM - Forum: Technical - Replies (3)

The living document for BOM is managed on Google Drive: https://docs.google.com/spreadsheets/d/1...sp=sharing

I also put together mouser carts for all the parts with a few exceptions:

The carts above are missing microphone, speaker, and standoffs.

TODO: I should feedback the mouser parts from the car into the main spreadsheet.

I should get my order today and start assembling. Always possible I missed something in consolidating to mouser.

Print this item

  TR-9 PCB, 4-layer
Posted by: pthrr - 07-31-2020, 01:58 PM - Forum: Technical - Replies (4)

Hello everyone,

this thread shall serve as a way to organize design decisions and improvements for the upcoming 4-layer version of the TR-9 PCB.

I suggest FR-4 substrate with overall thickness of 1.2 mm. We should design components for automated assembly.
Maybe already for a specific manufacturer(JLCPCB?).

The stack-up would be as follows:
-. 35 um Top
-> 300 um Dielectric
-. 35 um GND
-> 550 um Dielectric
-. 35 um VCC
-> 300 um Dielectric
-. 35 um Bottom

So nothing too wild. Let me know what you think.
We also could take copper off Top/bottom and/or add width to the core for a more common(cheaper?) 1.6 mm overall thickness.

- pthrr

Print this item

  TR-9 gerbers
Posted by: SP5WWP - 07-23-2020, 08:43 AM - Forum: Technical - No Replies

All gerber files are now available for download at our github. I have already ordered HMI and mainboards, 30 pieces of each.


Print this item

  2FA problem
Posted by: F4GRX - 07-16-2020, 11:34 AM - Forum: General discussion - No Replies

Hello, I cant activate 2fa on my account.

I get this error message:

The following errors occurred when trying to save your profile:

    You did not enter your password
    The password you entered was not correct

But I entered the correct password of course. I tried this several times with no success.

Can it be fixed?


Print this item

  "Review (kind of)", ideas and questions on TR-9 hardware.
Posted by: HB9DNN - 07-13-2020, 03:32 PM - Forum: Technical - Replies (8)

Hi everybody,

I finally found some time to read the TR-9 schematic. I take the freedom to comment a little bit on my findings. It is by no means thought as general critique on the concept. Nor is it a formal review as I don't think this is necessary in this stage of the project. So please accept my comments as positive feedback and food for thoughts.

1. Requirements specification
There is no top level requirements specification (at least I could not find anything). I understand that this kind of hassle is very often avoided (also in commercial projects) but I think it is very important. I might be a good idea to shortly sketch the design goals, most important interfaces (e.g. energy sources planned in the design), overall structure of the hardware.
This does not need to be a novel sized piece of art, a few lists and / or tables with requirements and maybe some diagrams are sufficient. This document will grow with the project.

2. Power requirements / consumption
So far I understand this should be a handheld device with limited battery size. Overall power consumption is quite important therefore. Now the definition of "low power" is somehow relative. If You ask somebody who works in the motor driver business he considers everything below a few tens of watts low power. If You are designing a LoRa module with 5 years+ battery shelf life You start to count electrons. My experience with several projects of the second kind taught me that permanent consumers are the ones to concentrate on. I found several possible candidates in the schematic which may severely limit battery life.

3. So lets turn to the schematic. I follow the pages and list (without specific order) my findings and / or questions:

a: OS1 is a "low power" (guess You expected the "" :-) ) oscillator. As used here it runs continously so the around 4mA are consumed no matter if its precision is needed or not.  The STM32 processors have a sophisticated clocking unit which, should the external oscillator fail will automatically switch to the internal oscillator (datasheet chapter 2.15). This could be used to save a considerable amount of power. The external oscillator can be disabled via pin 1. If its accuracy is not needed just turn it off. The internal oscillator will take over automatically if needed.
b. USB: The STM32 processor is ready for USB-C. Why not use it? Maybe something to postpone but USB-C is the future: high speed, higher power capability, batteries could be charged through it, etc.

3.2: well. Clearly under construction. May I make a suggestion?
- 2 18650 LiIon cells in series. Charger through USB-C, two DCDC converters for 7.5V (PA, Preamp) and 3.6V to 4V as preregulator for 3.3V LDOs for the rest. 7.5V DCDC converter can be disabled if not used to conserve power.

3.3: 5V really needed? I assume the TFT display chosen may need it, but this could be generated locally with a tiny step up converter.

3.4 Not many questions. I am not the expert on RF power amplifiers. What might be something for a future design is using a class-E design for its higher efficiency. But as we are talking about UHF here this may be just marginally more efficient.
I have a question though about the bias circuit. Does this opamp need 5V or would 3.3V be sufficient? If not could it run from +BATT? (again to get rid of the the 5V supply).

3.5 Audio output. The LM386 is an ancient amplifier chip. Certainly ok of the purpose it was designed for but as an audiophile I shiver from the sound it produces. I think it was Rick Campbell KK7B who first urged designers to use high performance circuits in the audio path. Not because Your squeeking signal will then sound like an opera singer but because it does not *add* further "squiekiness".
Apart from that the LM386 has quite a high quiescent current.
The STM32 used here has a digital audio interface (including I2S). It might be possible to use a class-D audio amplifier chip. Eg. the SSM2518 is a complete stereo amplifier with exceptionally high efficiency. Volume could either be set with a rotary encoder or reading a potentiometer value with one of the ADC channels.
Again maybe something for future iterations.

3.6: just a question: what is U11 intended for?

3.7: Looks like You want Wifi? Why not use an ESP32 in RMII mode? The STM32 does have such an interface and all the logic needed for Ethernet. Again: maybe even further in the future.

4. HMI Board: Is X1 needed at all? (power  consumption). Maybe this functionality could all be handled by an ESP32?

Just a few last notes on the overall structure. I like the fact that HMI is separated as much as possible from the rest of the system. This may allow to operate the radio "headless" through Ethernet in a later stage. I think of using the radio through a web interface (be it over a PC or smart phone) might be a nice use case.

Do You guys already have some experience on EMC problems of the design? What I am missing somehow are shieldings for sensitive parts (e.g. for RX and TX, particularly PA part).
I definitely expect some side effects from DCDC converters, no matter what topology is used. So it might be a good idea to shield the power supply section as well.

A last idea on the protocol: would it make sense to have some slow acting automatic TX power setting (using some nifty QOS data exchanged between the two stations involved)? This may help to keep radiated power as low as possible and additionally conserve power.

Puuh, that was quite a lot of babbling. I hope this was not too wooly and unconnected.

Questions always welcome :-)

Best regards und 73 Robert HB9DNN

Print this item

  M17 & ARISS
Posted by: SP5WWP - 06-27-2020, 08:02 AM - Forum: General discussion - No Replies

We have contacted ARISS guys some time ago. Looks like they might be interested in developing M17 and the TR-9 handheld for ARISS use (with an emphasis put on SSTV and APRS). Take a look at the last page of this presentation. There is a size limit for attachments, so I had to upload it somewhere else.

[url="https://m17project.org/files/download.php?id=34&token=f6mhRSkfy2vSgRIuBrVyEmzqA2LEumBK"]ARISS-I E2E 2020 FRIDAY 26 JUN, 2020[/url]

Print this item