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

Username/Email:
  

Password
  





Search Forums

(Advanced Search)

Forum Statistics
» Members: 210
» Latest member: iazwii9
» Forum threads: 84
» Forum posts: 548

Full Statistics

Online Users
There are currently 24 online users.
» 0 Member(s) | 22 Guest(s)
Bing, Google

Latest Threads
China Zinc Plated Wood Sc...
Forum: Reflectors
Last Post: iazwii9
4 hours ago
» Replies: 0
» Views: 3
Discount Ship To FBA
Forum: Reflectors
Last Post: iazwii9
4 hours ago
» Replies: 0
» Views: 3
Air Mesh Fabric suppliers
Forum: Reflectors
Last Post: iazwii9
4 hours ago
» Replies: 0
» Views: 2
Activated Carbon For Chem...
Forum: Reflectors
Last Post: iazwii9
4 hours ago
» Replies: 0
» Views: 3
China Face Masks manufact...
Forum: Reflectors
Last Post: iazwii9
4 hours ago
» Replies: 0
» Views: 3
China Food Packing Machin...
Forum: Reflectors
Last Post: iazwii9
4 hours ago
» Replies: 0
» Views: 2
China white square dinner...
Forum: Reflectors
Last Post: iazwii9
4 hours ago
» Replies: 0
» Views: 2
Integrated Ultrasonic Lev...
Forum: Reflectors
Last Post: iazwii9
4 hours ago
» Replies: 0
» Views: 3
Copper Products China
Forum: Reflectors
Last Post: iazwii9
4 hours ago
» Replies: 0
» Views: 2
Custom Solid Aluminum She...
Forum: Reflectors
Last Post: iazwii9
4 hours ago
» Replies: 0
» Views: 3

 
  PTT & OTA Requirements
Posted by: WX9O - 12-23-2020, 04:18 AM - Forum: Technical - Replies (1)

This is regarding the OTA protocol.

When PTT is keyed, what are the requirements?

What is required to happen if PTT is released while the preamble is being sent?

What is required to happen if PTT is released while the link setup frame is being sent?

What is the expected behavior when PTT is released while an audio stream is in progress?  Are there any requirements for how quickly the radio must stop transmitting?

Print this item

  new mrefd release 0.3.5
Posted by: n7tae - 12-22-2020, 03:53 AM - Forum: Reflectors - Replies (2)

This is not a critical update. 0.3.5 will allow multiple clients with the same IP and callsign to link as long as their connection ports are different.

Both mvoice and DudeStar use ephemeral ports making this possible. There is a very small chance (~1 in 10^4) that a subsequent client might try to connect on the same port as an existing client. If this happens, it will be refused. The solution is simply to restart the client so that it will choose another ephemeral port. This feature is configurable, so after you do a "git pull", be sure to rewrite your configuration file using "./rconfig".

This release also keeps its list of peers in alphabetical order, so the dashboard peers table will also be alphabetized.

Print this item

  An M17 gateway to HF
Posted by: alanVK2ZIW - 12-09-2020, 09:40 PM - Forum: General discussion - Replies (1)

Many country areas are not covered by VHF/UHF repeaters, can HF be made useful?

Background:
Our Australian emergency services are required by law to have an independent communication system.
So our country ambulance service vehicles and their bases have been fitted with HF radios and are going to
use the TWELP © digital modes.

In the FreeDV project, there are two apps and a stand-alone box to interface to one's HF radio. 
1) The FreeDV GUI app, PC and MAC.
2) The FreeBeacon reverse beacon
3) The SM1000 stand-alone interface box

But with so few amateurs using any of these, there's rarely anybody to talk too.
What's more, doing search and rescue, HF in vehicles is  easy on 40m and 20m
but if the HF conditions put one's signal 1000Km away, how does one  contact the
in town HQ. This is where a network of HF base stations comes to play. (as in my ambulance example)

I'm not a C or C++ guru programmer, so this is my approach (on Linux):
"connect" modified FreeBeacon (cnode.c) to "mvoice" via the loopback pseudo devices.
Pass PTT too and fro via semaphores.

Any thoughts?

Print this item

  packet data format
Posted by: ah-huh - 12-04-2020, 12:33 PM - Forum: Technical - Replies (2)

Hello,

The format of the M17 protocol packet data communication is undefined?
I will implement short messages client on M17.

Print this item

  M17 Reflectors Open Alpha
Posted by: KC1AWV - 11-28-2020, 06:21 PM - Forum: Reflectors - Replies (6)

In order to separate tasks and duties, a new M17 Reflector and Group registration system is available and open for open alpha testing.

M17 Reflectors

Using the alpha M17 Reflectors system, you can self-register and update your reflector information. You will need to register your reflector yourself on the new alpha system, the records from the old list and the new one are incompatible.

Registering your reflector requires the following information:

  • Designator - This is the 3 characters after the M17- that identifies your reflector, i.e. USA, or BRO
  • Dashboard URL - This is the address for your reflector dashboard. This must start with https://
  • IPv4 - The public IPv4 address to your reflector
  • IPv6 - The public IPv6 address to your reflector (optional)
  • Port - The UDP port your reflector is listening on (generally 17000 unless you've changed it)
  • Sponsor - The sponsoring amateur radio station or club
  • Country - The country served by the reflector

Once your reflector is added, it will be in a Pending state until reviewed by a Reflector Admin. Once approved, the status will change to Published and cannot be accidentally deleted. You can change the status to Deleted and remove the reflector yourself if needed.

Features to be added:
  • Group Registration
  • Email reflector and group admins on new registrations
  • Reflector and Group list API (to generate host files)
Questions, comments, and ideas can be sent here as a reply to this thread.

Steve KC1AWV

Print this item

  new version of mvoice
Posted by: n7tae - 11-19-2020, 05:40 PM - Forum: General discussion - Replies (18)

A new version of mvoice (201118) is available. It's now easier than ever to connect to an M17 reflector. Start mvoice with "./start-mvoice" from your build directory and this script will download the latest connection information about all registered M17 reflectors. Select a reflector from the drop down list, select a module and link and you are connected. Once you've selected a registered reflector, use the "Open Dashboard" button to see its dashboard.

Depending on how you set up your system, you can still start movice with "./mvoice" or "bin/mvoice" or simply "mvoice" if you don't need to update your registered reflectors list.

If you've selected IPv6-only operation, your drop down list will only contain those registered reflectors that support IPv6. There are only two currently, M17-M17 and M17-USA.

The format for saved destinations has been changed and so mvoice now uses a different file, ~/etc/M17Hosts.cfg. The downloaded registered M17 reflectors are in ~/etc/M17Hosts.csv. (Thanks to the dudestar guy for this!) Your previously saved Destination callsigns/IPs are still in the original file, ~/etc/M17-destinations.cfg.

Several bugs with the settings dialog have been fixed.

If you already are using mvoice, go to your build directory and do "git pull" followed by "make install".

Print this item

Smile ORI sponsors the M17 Project
Posted by: EA7IYR - 11-17-2020, 11:15 AM - Forum: General discussion - No Replies

Open Research Institute is proud to formally sponsor M17, an open source digital radio protocol, code, voice codec, and hardware project. The designs and technology are highly useful for digital radio uplinks for a wide variety of amateur satellite projects. The project is dynamic, international, accessible, modern, and welcoming. Open Research Institute is a 501©(3) dedicated to open source research and development for the amateur radio satellite service and beyond. Find out more at https://openresearch.institute

Print this item

  TR-9 RF power amp and lowpass part
Posted by: SP5WWP - 11-14-2020, 03:42 PM - Forum: Technical - No Replies

I have a test setup comprised of an ADF7021 tied directly to a circuit shown below

[Image: E5KMytC.png]

The problem is that the power output is too low and the RF MOSFET gets hot pretty fast.
The frequency response of the lowpass part is far from being optimal. 2nd harmonic is at -10dBc. I have already proposed a change here: https://github.com/M17-Project/TR-9/issu...-727211097

Sources:
http://www.elenota.pl/datasheet-pdf/1613...448ed59464 (page 10)
https://www.nxp.com/docs/en/data-sheet/AFT05MS004N.pdf

Print this item

  New mrefd release 0.3.4
Posted by: n7tae - 11-13-2020, 12:57 PM - Forum: Reflectors - No Replies

Mrefd 0.3.4 is available. This is an important release and everyone should upgrade.

This release more efficiently handles the whitelist, blacklist and interlink files. Any invalid entries in these files will be flagged with an error message and be ignored. If you want an open reflector, remove all entries in the whitelist file, including the "*" entry. An empty file means "all are welcome". If you are having trouble with a user on your reflector, add their callsign to the blacklist with a trailing "*". If they are currently logged in, their transmissions will be blocked. You will see this in the log. Once they log out, they will no longer be able to log in. All configuration files are case insensitive.

The C++ container used to internalize the mrefd.* configuration files have been changed to more efficient containers. the black and white list now use std::unordered_set and the interlink now uses std::unordered_map. These new containers are much more efficient and will save cpu cycles on your server, particularly so for the interlink data.

An important bug was corrected having to do with how streams are terminated.

Please upgrade your system at your earliest convenience.

Print this item

  A few notes about how to link reflectors
Posted by: n7tae - 11-10-2020, 09:08 PM - Forum: Reflectors - Replies (3)

Mrefd uses a mesh model of interlinking developed by the xlxd team. First of all, any particular connection has to be configured on both ends of the connection. We'll call a collection of interconnected reflectors a group. The smallest possible group contains  two reflectors. Once the link is established, clients on one reflector can hear and be heard from clients on the other reflector.

A group can share multiple modules. If they do, traffic on one of the shared modules will not be heard by clients linked to the other modules in that group. A reflector may participate in multiple groups, but any given module can only be in a single group. Once a module is assigned to a group, it should never be configured to be in another group.

With larger groups, each reflector in the group must link to every other reflector in the group. Consider a group of three reflectors, M17-001, -002 and -003. Each reflector needs two entries in its mrefd.interlink file pointing to the two other reflectors in the group. Traffic is managed in this more complex group by a "one hop" policy. This policy prevents "looping" that might arise in the the older styled "train-car" linking. Here is how mesh linking works:

When a client on one of the group modules sends a voice stream to its reflector, the reflector sends it to all its linked clients, including other linked reflectors. However, the voice stream directed to another reflector is marked with an extra byte. When the receiving reflector gets this voice stream, it can easily identify that it is from a reflector and not a normal client so it will only pass the stream to its normal clients, not to other reflectors in the group! A stream is only relayed one time within a group.

If a group is missing a link in one of the connections, all clients on the group may not be able to hear everyone else on the group. Let's say in the example above M17-003 hasn't yet got around to configuring the link to -002. In that case clients on -001 will hear everyone, but clients on -002 won't hear clients on -003 and vis versa. That can be very confusing for clients listening to the group module. Administrators can usually easily tell if something is wrong by monitoring the mrefd logs, "sudo journalctl -u mrefd -f". If a link is only configured on one side, both sides of the link will see the attempted link fail, over and over again. See the attached file for an illustration of a good and bad four-way group.

Administrators that want to join an established group need to communicate with all of the current group members. It's also a good idea for group members to occasionally look at the dashboards of each of their group reflectors to be sure there aren't "dangling" members connected somewhere on the group.



Attached Files
.pdf   M17Interlinking.pdf (Size: 11.15 KB / Downloads: 24)
Print this item