feb 27

Geen regio onderscheiding meer in het CSS7 ID

De admins van de DMR-ID (CCS7) registratie, in Nederland is dat William PE1BMM hebben te horen gekregen dat er niet meer op de regio geregistreerd kan worden in de database. Als reden wordt aangegeven dat men geen noodzaak ziet tot het registeren van een regio en laat men dat nu dus los. Hieronder de originele berichtgeving!

Hi admins of the DMR-ID registration system for Europe and Africa!
I have got a few emails with questions about recent changes.
I am sorry, I wanted to send out some information on it to all admins earlier, but I was very busy, travelling for work last days and in addition a few things came up surprisingly.
We had some issues after the US database lost 2500 repeater entries in January and it was all deleted here 3 weeks later after it was not refreshed.
The admin of the US system told me about some issues with the generation of the API files which are used to exchange the data between our systems and for other applications.
After a few days they fixed it, the missing repeaters returned, were newly created in our system, but additional configuration information for DMRplus-repeaters, that we have stored in our database for the whole world, were gone for all repeaters outsite of EU/AF.
177 repeaters no longer brought talksgroups and reflectors like sysops and users expected.
So I spent some time day and night to extract that details from old backups and restore it to the system.
I could just fix it before I had to go to a business trip.
Parallel some systems which use our APIs to get user- and repeater data crashed over night and claimed about an issue with html-redirections.
I have no idea why that happens, we had no change with the different APIs since last year.
In the past we had 2 servers running with 2 different domains, ham-digital.net in Switzerland and ham-digital.org in Germany.
This changed last year, the Swiss system was closed down and incoming requests redirected as long as the system was still there.
Since January the system in Switzerland is gone, switched off, no redirection anymore.
Suddenly on last Monday the systems all crash and claim about a http- to shttp-redirect for the API access…??
I have no idea why.
The registration server is shttp/ssl-encrypted since 2018, there was no change.
Not even the certificate was updated during last days, the actual version is from Nov 2019.
The software on the attached systems also did not change and worked for several weeks before.

I tried my best but could not change anything on server side, the affected IPSC systems finally all had to be updated.

However, we had some other changes that I discussed with some of you already since last year.
2 main topics:

  1. DMR-IDs no longer shown on the web before approval

2. No regions anymore within countries

  1. Visibility of DMR-IDs before approval
    Some of you contacted me after in some countries people register for a DMR-ID, do not provide correct or complete data, but take what is shown on the web, even if it cannot be approved. It is often hard or impossible to get the missing information from them.
    To prevent that we decided to no longer show the DMR-ID before it has been approved.
    This may cause an issue if the email address was entered wrong or the receiving mail system moves the automatically generated email to the spam. In that case users might need to check on the webpage if their request was approved and what DMR-ID was assigned.

This change is not new for all countries, we always had countries where the DMR-IDs were not shown during the registration.

  1. Regions:
    Let me start with some numbers before I explain why that changes were inplemented:
    We have currently about 160000 user registrations worldwide, about 70000 in  our system for Europe and Africa, most of it in Europe.
    We support 50 countries in Europe and about the same number in Africa.
    We have 480 prefixes in the system worldwide, many of it in EU, AF.
    The first 20 countries in Europe which startet with DMR had been divided into regional structures by the former admins.
    They created 377 regions in Europe in that 20 countries.
    This was done at times when the registration was still done manually in an Excel sheet and copied manually to the US database.

Incredible today, where we have 2500 new user registrations per month.
The regions were defined in each country individually based on different criterias, counties, states, bigger cities, Departements, Bundeslaender, Kantons, Zip code areas, the numbers in Callsigns etc..
Many different ideas how to build a structure below the official ITU MCC system.
When we set up today’s registration system we tried to implement all of that different rules and followed automatically.
It was a hard work and I did not ask at that times for what this features could ever be useful.

Later new countries were never split into regions, therefor we still only talk about 20 countries out of about 100 where we had that regions.
So if you do not know what this is about, you may be in one of the countries where we did never have that local regions.
But exactly these 20 early countries are those with a high number of registrations today.
Many different reasons came up during last years why I decided to give up this splits.
To mention just a few, some admins may know more from earlier discussions:

  1. No real requirement or benefit
    There is no need and no benefit at all that we can take from that region information.
    It cannot be used for routing or any other useful feature of the network.
    This makes it an issue if critics comes up and legal questions. Why do we do it without any need and benefit?
  2. No maintenance
    Nobody maintains the regional assignment of DMR-IDs, for example when a user moves from one region of a country to another.
    This means that the regional digit in the DMR ID only says where a user lived when the ID was assigned, but it may not be actual.
    If you collect data, people have the legal right to have it maintained, corrected or removed when it is no longer needed.
    For what is the local region needed?
  3. Limitation of address space
    Most important, the regions limit the available IDs in many of that 20 countries in high populated areas and leaves a lot of address space untouched in other regions with lower population.
    Italy, Germany, UK, Spain, France, … were the first countries which run regionally out of address space, in Germany meanwhile several times.
    In such a case I have to configure the system manually and define which new block of IDs to use next because it is usually not the next block.
    There is no fix rule, the next free block is different for every country and every region and possibly there is no free block at all and regions have to be combined.
  4. Additional workload and issues
    In the last months this created more and more additional work (20 countries with 377 regions!) and for several weeks people could not get any DMR-ID because nobody told me that a specific block was full.
    Complains usually blaim the system or the local admin and it takes long time until people tell me about it.
  5. Change management
    In some countries people asked to change the existing regional structure, to have new names and borders of regions, move address blocks around… They believe that the current system is not good and could be improved.
    New work for what?
  6. Data privacy… !
    People claim about issues with data privacy.
    I cannot hear that word anymore, but with a database full of personal information we need to be very careful with it.
    The region/home location is a personal information that is not required to run the system, so we should not collect it in a database and show it in public.
    One main point of data privacy is “Don’t collect any data that you do not really need”.
    This brings me back to my question from above: “Why do we do it?”. For what do we need it?
    Maybe somebody can explain me for what we need that information and what to argue against data privacy concerns?
    I did not find anyone yet – other than “it is nice to have”.
    People reject to give us their surname and location, but we expect to tell us where they live and show it indirect to everybody on the world.
    I do not want to run into any legal issues.
  7. Political reasons / dividing users

Finally we had the request to have different admins for some regions for political reasons.
We are Radio Amateurs and talk about worldwide friendship and communication, but obviously we have some issues with that in our own rows.

Without any regions this upcoming discussion is stopped.

As a result the regions have been removed for these 20 countries.
The system no longer askes for a region during registration anymore.
All lists with different assignments are gone.
DMR-IDs are now assigned from buttom to top accross the whole MCC range which have been assigned to a country by the ITU.
I hope everybody can live with it and complains will calm down.
If somebody can give me a real requirement where we need it locally, I can reactivate it exceptionally.


Now that I address you all, I would like to add a few other information which are brought up to me regular:

  • Verification of licenses
    We won’t provide a DMR-ID to people who don’t tell us their name and who reject to prove that they are the legal owner of a callsign.
    The quick way would be to scan a copy of the license document and upload it.
    People who have concerns may send it to the admin by postal letter or may visit him personally and show it or in any other reliable way.
    The idea to check information at qrz.com is not acceptable in my eyes.
  • I very high number of users do not have a qrz.com account.
  • There are several alternative systems, we cannot check it all.
  • These systems are not reliable, the information may easily be faked.
    As an example: Every user of qrz.com can create, maintain and remove any other callsigns with all information.
    The first is checked and approved before you get an aoccount, but others can be added without approval.
  • If people show their personal data there, why not direct to us?
    As a sysop of several repeaters I do not trust people and allow them to use my personal internet line who do not trust me.
    Legally I am personally responsible for what I take from the internet and send out on Amateur Radio, so I rely on all of you admins to provide IDs only to people with a valid license.
    Yes, a DMR-ID can be abused, but we have the same issue with every callsign.
    This is a problem that the authorities have to fix, not ours.
  • No over-regulation
    On the other side we should not introduce more limitations than the authorities.
    If they don’t care about some special applications and experiments, it is not on us to prevent these things.
    Amateur radio is an experimental hobby and especially with DMR the authorities accepted already in very early days exceptions to international rules when they allowed us to use numeric DMR-IDs, coordinated on our own, instead of the official callsign with every transmission.
    Whoaver has a valid Amateur Radio license should get a DMR-ID.
    It is our job to assign a DMR-ID to a callsign.
    It is not our job to decide about a good or a bad guy, somebody who is member of a good team or a bad team.
    Let us leave it to the repeater and network sysops to block people individually in case of real issues and report it to the local authorities like it is required usually.
  • Issues with uploading documents
    Users complain frequently that they cannot upload their scanned license copy.
    Let them please check the size of the image.
    The system accepts max. 500kB. This is pointed out next to the upload button in fat red letters, but obviously nobody reads it.
    We cannot accept pictures from todays smartphone cameras with 10, 15 or more megabytes from hundreds and thousands of users.
    Also some of us check the registrations during travels on the mobile phone and have to download the pictures for expensive rates.
    It is normally no problem to choose a lower resolution before sending a picture from the camera.
    Unfortunately I did not find any easy way yet to return a meaningfull response after the upload with the current script system.
    The upload task gets the limit and acceaptable file formats and it rejects the file if it is different.
    People should please sometimes check for own mistakes first.

After 8 years and 70000 registrations the chance is high that it is not necessarily a mistake of the system.

However, the case from last days where people from outside of EU/AF could no longer login to the sysop pages showed, that new issues may appear even after years. 🙁

I hope that this answered a few questions which came up last days and everybody can accept the changes.
Thank you all for your work, day by day, without weekends and holidays.
Without it it would not work.


Vy 73
Hans DL5DI

feb 25

Yaesu FTM-300DR C4FM Dual-Band

Yaesu FTM-300DR 50W C4FM/FM 144/430MHz Dual-Band Digital Mobile Transceiver

The new FTM-300DR provides stable and reliable 50W RF power output. As in recent YAESU mobile transceivers, the FTM-300DR is also equipped with a heavy-duty heat sink that includes our exclusive FACC (Funnel Air-Convection Conductor – Wind Tunnel). 

Real Dual Band Operation (V+V, U+U, V+U, U+V) is available with two independent receivers, and the FTM-300DR supports simultaneous C4FM digital monitoring for both the A and B bands.  

2-inch High-Resolution QVGA Full-Color TFT Display clearly highlights the frequency and operation bands.

With the Band Scope Function, users can monitor up to 63 channels centered around the current VFO frequency in real time. (21 channels in memory channel mode)

Memory Channel Band Auto Grouping (MBAG) is one of the advanced features of the FTM-300DR. Memory channels are automatically categorized in each band, and memory channels can be easily and quickly recalled by 4 Band Groups – Airband(M-AIR), VHF(M-VHF), UHF(M-UHF) and 174-400MHz/ 480-999.99MHz (M-GEN).  

3W audio power speaker ensures a clear and crisp audio – that has been specifically tuned for quality audio. Two individual external speaker jacks are provided. Users can output the VFO A and B band Receiver to separate speakers or mix A and B signals when a single external speaker is used. 

Built-in Bluetooth unit is installed in the FTM-300DR. This enables the hands-free operation with the YAESU SSMBT10 or a commercially available product. The SSM-BT10 is equipped with a PTT button and also supports VOX operation. Using the new USB charger cable – SCU-41 with the controller of the FTM-300DR, the SSM-BT10 can be easily charged. The SSM-BT10 works for approximately 20 hours on single charge.

The FTM-300DR supports both the WiRES-X Portable Digital Node function and Fixed Node function with the HRI-200. Since simultaneous C4FM monitoring on both VFO A and VFO B is possible, users can enjoy both WiRES-X communications on one channel while monitoring another local channel at the same time.

Other advanced features of the new FTM-300DR include

  • DG-ID (Digital ID)
  • Group Monitor
  • Positional awareness from the built-in 66ch High Sensitivity GPS receiver enabling Real Time Navigation
  • Backtrack feature
  • A GPS Terminal for an external GPS receiver
  • 1200/ 9600 ARRS data modem for ARRS mode
  • Voice Recording of both Received and Transmitted audio
  • Save and load data including configuration and memory channel information to a micro SD card
  • Snapshot function using the optional MH-85A11U camera microphone
  • $539.95