Tue, 2 Apr 2024

What should you know about M17?
The M17 is a radio technology developed using open source hardware, software, and offer a complete digital radio protocol for data and voice, made by and for amateur radio operators.
The protocol’s voice mode uses the free and open Codec 2 voice encoder. This means there are no patents, no royalties, and no licensing or legal barriers to scratch-building your own radio or modifying one you already own.
.
This freedom to build, understand and innovate is core to amateur radio, but has been missing from the commercially available digital voice modes. This is part of why amateur radio digital voice modes have largely stagnated since the 1990s and we’re almost wholly dependent on commercial products that aren’t well designed for amateur radio users.
.
M17 is about unlocking the capabilities that amateur radio hardware should already have.
Here you will find people working on radio hardware designs that can be copied and built by anyone, software that anyone has the freedom to modify and share to suite their own needs, and other open systems that respect your freedom to tinker. (taken almost verbatim from https://m17project.org/)
.
What is unique about the CS7000 M17 radio?
This radio will be both DMR compatible and M17 compatible. By having a radio M17 compatible, you now open up the possibilities of quickly flashing other protocols into the radio such as Fusion, DSTAR, NXDN and others.
With other radios, to completely reflash the radio requires you to take apart the radio, short two pins and then turn on the radio to get into a special downloading mode. With this radio you press the top button and turn on the power to get into the special downloading mode.
.
What is unique about the CS7000 M17 PLUS radio?
Besides all the features of the basic CS7000 M17 radio, this radio will double the amount of code memory, about three times the amount of internal ram memory and run about three times faster.
This will allow the HAM community to advance the state of the art in communication technology and have the first true multi-protocol digital radio.
.
Connect Systems M17 Radios
We are developing two radios based on an existing radio from our manufacturer. This M17 radio is going to be a modified CS760. To be true to the M17 project, schematics and a parts list will be provided so you can make your own. However, as part of the design, for the CS7000 M17 we will allow you to load at will either the M17 firmware or the DMR software.
.
If you wanted to make your own radio, the DMR software will require you to spend a few hundred thousand dollars for the AMBE II vocoder firmware, the radio and battery tooling will cost about $80,000 and you will need to find someone to build it for you. The parts are so small in the radio, you need to either go to someone who has the capability to build the radio or solder it yourself under a microscope. Using three-dimensional printing technology, it is possible to build the case and battery holder yourself for a nominal cost thereby saving the $80,000 in tooling cost.
.
Why buy CS7000 M17 when you can get a cheaper M17 radio?
There are some inexpensive Chinese radios you can modify to do the M17 protocol. If you have the tools and ability to work with small SMD parts you can save a little. With the CS7000 M17 we do it all for you and it is plug and play.
.
The CS7000 M17 is a much better radio than the cheap Chinese radios. This radio is Part 90 certified, manufactured to commercial standards and has a frequency range of 400-512 MHz. The other radios are typically 400-470 MHz and designed to amateur standards. Many of those radios are not Part 90 certified.
.
Why should you get the CS7000 M17 PLUS?
The CS7000 M17 PLUS was designed to have multiple protocols in a single radio. The CS7000 M17 can only have a single protocol at a time. The DMR protocol takes between 500,000 and 1,000,000 bytes of code depending on the features you have. The M17 protocol takes about 400,000 bytes of code. There is a lot of overlap between the code that the DMR protocol takes and the M17 takes so in theory the combined will take a lot less than the sum of the two.
.
The DMR or M17 protocol takes most of the available resources of the computer running at 168,000,000 instructions per second. The CS7000 M17 PLUS microprocessor will run at three times the speed thereby allowing you to develop better algorithms and have more features than you can have with the basic radio.
.
What can a more powerful M17 radio do?
We can change the modulation from 4FSK to 16FSK. That will allow us to reduce the bandwidth in half. We can change the vocoder to work at half the data rate. This will again reduce the bandwidth by two. With these two features we can have four channels in a bandwidth of 6.25 KHz. If we use the bandwidth of the old analog channel, we can have 16 channels of voice compared to the single channel of voice that we used to have. If we use it for data, we could double the transmission speed.
.
We can put in an AGC for the voice so the voice level will sound the same no matter how softly the other person is speaking.
I am sure the amateur community will develop other features that will advance the state of the art compared to commercial radios.
.
What is Connect Systems Role in this project
We are doing two things. We are paying to have one of the key designers of the original M17 radio implement what was done before in the cheap Chinese radios in the CS7000 M17 and CS7000 M17 PLUS.
.
We are coordinating and paying the manufacturer of the radio to make the necessary changes to make the CS7000 M17 and CS7000 M17 PLUS radios.
.
Status of CS7000 M17 Project
1. Have manufacturer send sample radios to engineer to modify and test. Completed
2. Have engineer pay import duties and receive radio. Completed
3. Determine changes necessary to put in radio. Completed
4. Put changes in radio and test to verify changes work. Pending
5. Modify software from working M17 radio to be compatible with CS7000 M17 radio. Pending
6. Improve performance of radio. Pending
7. Release radio for limited beta testing. Pending
8. Ship to new radios to customers who prepaid. Pending

Mon, 29 Apr 2024

STATUS OF M17
The follow is the status of the M17 project as reported by the developer.

Hello Jerry,

The current status of the work is:

1) I spent a week or so reverse engineering the original firmware in order to extract the LCD intialization sequence, where the calibration data is stored in the external flash, how calibration values are used and the initialization sequence of the HR_C6000. As planned and anticipated, there is still some work to do on the HR_C6000 by sniffing the SPI communication with the MCU, because the information I got from the firmware do not give me a complete insight of the situation.

2) basic boot code is up and running. The radio has a CKS32F407VGT6 instead of an STM32F405: this caused some troubles because it seems that the code compiled with optimization level -Os (optimize for size) fails to configure the clock tree properly, while compiling it with -O0 (no optimizations) solves the problem. I suspect some quirks with the data cache or with the transactions on the APB bus (the latter being a known problem also for the STM32F42x MCUs). For now I'm compiling the code with -O0 and calling it a day, I'll investigate further in the future.

3) hardware mods almost finished, eye diagram of baseband signal in TX is satisfying and now I have to test it over RF. The fact that I get a good signal at HR_C6000 input still does not ensure that the modulation of the RF carrier is good, but I'm not expecting surprises. Tests over RF are required also to sample the demodulated baseband and plot the eye diagram to assess the effectiveness of the modifications. For the BOOT0 mod I'm observing some weird behavior despite the modification I did is very simple: the plan is to replace R686 with a PNP transistor with its base connected at the node between R679 and S404 so that, when the "alarm" button is pressed, the base of the transistor is shorted to ground and BOOT0 is pulled to 3.3V. However, for some reason which I haven't identified yet, the voltage on BOOT0 has a small spike at 3.3V and then settles down to 1.65V, which is not enough to make the MCU go in bootloader mode. An alternative modification is to swap the places of S404 and R679 and connect BOOT0 ALARM_KEY together such that, when the button is pressed, they both go to 3.3V; I don't know if CoValue agrees on doing this, though.

4) I wrote the drivers for the display and the keyboard (you can find a picture of the screen attached) and now I'm moving on to bringing up the RF stage, since I need it for the validation of the M17 mods. Bringing up the PLL and RX path should be fairly easy, I'm expecting more troubles when I'll have to work on the TX side and for this I'll for sure need to do some reverse engineering work on the HR_C6000. One issue I have to solve, which is for caused by incomplete information on how the baseband chip works is a frequency offset of +600Hz with respect to the frequency set in the VFO, which has been observed both on the MD-380 and MD-UV380 with both OpenRTX and OpenGD77.

By the way, with Wojciech SP5WWP we have the intention of showcasing a CS7000 (it can be one of my prototypes) at the M17 boot at Ham Radio Friedrichshafen at the end of June.

Wed, 8 May 2024
STATUS OF M17

The follow is the status of the M17 project as reported by the developer.

Hi Jerry,
I'm sending you the new document, with the updated modification to the mic path and a description of the reasons for the changes.

I'm not against having my name mentioned, if you want to do so. :)

Silvano Seva

About this project
There are two people primarily responsible for the development of the M17 project.

Silvano Seva who is the primary person for the firmware and
Wojciech Kaczmarski who is the primary person for the hardware.

If there are other people involved, I am sure I will hear about it and will include it in future blogs.

Date: Sat, 18 May 2024 16:07:17 -0400 (EDT)
From: "Connect Systems Inc." 
Subject: BLOG OF THE M17 PROJECT

To the furtherance of the M17 project, I want to add D-STAR to the CS7000 M17 PLUS radio. The basic work has already been done in the MMDVM. The only real issue is the Vocoder. While there are some D-STAR vocoders, none of them is as good as what DVSI sells.

The D-STAR vocoder was first used in the ICOM D-STAR radios over 20 years ago. That means that the underlying patents are now expired. However, that does not mean the Copyright has expired because Copyrights are now good for about 99 years thanks the Micky Mouse and Disney.


To get around Copyrights with a Vocoder, you take the patents and write from scratch the code to make the D-STAR vocoder. As long as you did not copy the vocoder made by DVSI, you are clear. However, by writing the new code, you might now be infringing on some new patent of DVSI or some other company.

The get around the potential patent and copyright issue, I made an offer to DVSI. For every CS7000 M17 and CS7000 M17 PLUS radio we sold, I would give them a $2.00 royalty against them making a claim that the D-STAR vocoder in the radio infringed against their patents or copyrights. This is in addition to the royalty they already get for the AMBE II Vocoder we use to support the DMR features. We were not asking them for the firmware of their D-STAR vocoder.


The royalty concept was competed rejected. If I want to use the D-STAR vocoder, I need to pay them an up-front fee of about $350,000 plus royalty for every radio I sell. My alternative was to buy their AMBE 3000 series chip for $22.


For a company that is going to sell between a hundred thousand radios and a million radios like Motorola and ICOM, that up-front fee is no big deal. For a smaller company, that up-front fee is outrageous.


While that $22 fee for the AMBE 3000 chip is acceptable, it puts us at a significant technical disadvantage compared to the larger companies. The first problem is the AMBE 3000 chip takes a significant amount of power which means the battery life will be significantly less compared to the larger companies. The second issue is the AMBE chip takes room on the PCB which means my radio will now be larger compared to the larger companies.


In my opinion DVSI is in violation of the Sherman Anti-Trust laws. Because of their policies, it is not possible for a smaller company to compete against the larger companies as described above. However, to fight them, would cost more in legal fees than their outrageous up-front fees.


My suggestion for the Amateur community is to make the best vocoder you can and if DVSI then says you are breaking their patents, ask which one so you can then fix the problem. If they complain about copyright infringement, ask how they can be in violation of their copyrights if they have not released their code to copy. If you reverse engineered their code, go out of your way so you are not infringing.


Here is an interesting question. If I bought a AMBE 3000 series chip and put it in the radio but did not hook it up and then I duplicated their code and ran it in the radio, would I be infringing on DVSI intellectual property?

Date: Wed, 19 Jun 2024 21:56:35 -0400 (EDT)
From: "Connect Systems Inc."

STATUS OF M17 PROJECT

The two production radios have shipped to the developers as promised late last month. The status of those radios are shown below. The production radios are now ready to be modified and shipped to the customers who have already bought the radios. I will generate another email blast when I have a more definite date on shipping to the customers who have already bought the radio.

If you are in Europe and going to the Ham Convention, you should see the production radios in operation.

(JUNE 18)
Hi Jerry,

Hardware modifications are good to go, both TX and RX work and the transmitted audio is loud.

I just want to see if changing a resistor on the baseband path improves a bit the modulation quality, but is not a mandatory change.

Bye,

Silvano.

(JUNE 14)

Update: RX works, TX needs some more adjustment because the transmitted signal is distorted. I need to investigate further where the problem is.

Bye,

Silvano.

Date: Fri, 19 Jul 2024 18:38:42 -0400 (EDT)
From: "Connect Systems Inc."

STATUS OF M17 PROJECT

The CS7000 M17 has started shipping. The first two has shipped to Japan. The rest will ship either Monday or Tuesday. They would have shipped yesterday but the manufacturer forgot to include the programming cables. The cables are being shipped by DHL and they suppose to be here on Tuesday. I am hoping they will get here on Monday.

All the radios are packed along with the USPS labels on the box. Only need to put the programming cable in the box and close it.

Once we start shipping those radios, the price will go from $249 to $299. As I said in an earlier email, the discount is because the early buyers are in effect subsidizing the production and I thought they should get a discount.

The CS7000 M17 PLUS is coming along but we did have one hiccup. The manufacturer wanted to make sure the DVSI vocoder will work on the M7 version of the ARM microprocessor. The current microprocessor is the M4 version of the microprocessor. They are going to try it and should get the results in a few more days. ST micro says the M7 is backwards compatible with the M4.

I thought I would find out about the compatibility myself by asking DVSI, the originator of the vocoder. They had a nasty attitude and told me unless I was the licensee of the vocoder, they would not tell me.

I started out by calling them and the person I needed to speak to was not there. I left a message and they never called me back. Because they did not call back, over the next two days I called a few times per day hoping I would get someone. No one answered when I called them. Then they asked me not to call so much. If they answered and told me they would not give me an answer I would not have bothered them again.

Over the next few days you will see an application note on our website on how to convert from DMR to M17 and M17 to DMR.

Date: Sun, 21 Jul 2024 15:34:50 -0400 (EDT)
From: "Connect Systems Inc."

The CS7000 M17 PLUS will ideally have three or four vocoders available for the firmware.

1. AMBE + 2. This is a fully licensed vocoder from DVSI and is used for the DMR, Fusion, NXDN and P25 Phase II protocols
3. Codec 2 to support the M17 protocol
3. AMBE vocoder to support the DSTAR Protocol
4. IMBE vocoder to support P25 Phase 1 protocol

I have a few questions for the Amateur community. Ideally you will give me a copy of any case law that might apply. Also, does anyone have a recommendation for a lawyer that actually understands intellectual property law as it relates to software.

The purpose of these questions is to get as much information as possible before I contact a lawyer.

It is my understanding that the vocoder used for the DMR radios is stored in the flash memory of the microprocessor encrypted and when the radio is turned on, there is a chip on the radio board that decrypts the code and stores in in RAM to be executed. This is to prevent the Chinese from stealing the intellectual property of DVSI.

The question I have is if someone was to take the unencrypted code and store in in flash, what grounds can DVSI sue us for. Remember, we are (through the manufacturer) already paying the royalty for their firmware.

DSTAR has been around for over 20 years and obviously the vocoder for that product is no longer protected. The current DSTAR vocoder used in the AMBE 3000 vocoder chip might be protected under other patents.

The question I have is there any good DSTAR vocoders available and what is the risk of using it. What would happen if you gave a copy of that DSTAR vocoder to DVSI and tell them you are planning to use it unless they can show you it is in violation of the intellectual property. The reason for asking is because if they make a claim, then you have a possibility to redo the firmware so it no long interfers with their rights.

IMBE has been around a long time. Does anyone have a good IMBE vocoder?

Does anyone know of interesting case law as it applies to issues of putting a vocoder in a radio. I would have expected that the design of the Codec 2 would have had similar problems. How did they resolve it?

Date: Mon, 2 Sep 2024 14:12:34 -0400 (EDT)
From: "Connect Systems Inc." 

Blog Of Why We Designed Something A Particular Way

This blog will explain why we picked the STM32H743 for the CS7000 M17 PLUS and not continue with the STM32F405 used in the CS7000 M17.

The answer lies in the objective we were trying to achieve and over 50 years of experience with computers and software.

The objective was to make a radio that can not only do M17 but also do all the other digital formats used in modern radios such as P25, NXDN, Fusion, DMR and others. There are two issues to achieve that objective. The first issue is the amount of program memory needed and the second issue is the speed of the computer.

We know that the DMR radios with all the features available take about one megabyte of memory. If you leave out many of the features, you can get the memory size down to 500K. If you now have eight different digital protocols, you could be looking at close to 8 megabytes of program memory. That could be reduced somewhat because you have many common routines with the different protocols.

We know that DMR radios work just fine with the STM32F405 radios running at 168 MIPS. However, those radios have a baseband chip which greatly reduces the speed requirements. We also know the M17 radio works with the STM32F405. What we do not know is what speed do we need for some of the other formats.

The STM32F405 uses up nearly all its ram memory and program memory for doing DMR and Analog. So obviously that part will not work for multiple protocols. However, if we take out many of the DMR features, we might be able to accommodate another digital format such as M17 or Fusion. The STM32H743 has double the code memory and three times the RAM memory so we might be able to fit most of the protocols in that chip. However, that is not enough because the objective is fit all the protocols in the radio. We also need more memory for features that have not even been contemplated.

The solution was developed over 50 years ago by IBM and possibly others. They called the solution “overlays”. Microsoft later gave it a fancy name called “virtual memory”. The first time I have seen it was in an IBM 1130 minicomputer over fifty years ago. This computer had eight thousand words of memory. The more expensive version of the IBM 1130 had sixteen thousand words of memory. The programs that I used sometimes needed hundreds of thousand words of memory. The hardware was primitive and did not have floating point support.

The solution was clever. You saved some space in RAM for code memory. If you needed to do a floating-point multiply operation, you found the routine on its disk and put it in RAM and executed it. If you next needed to do a floating-point divide, you found the routine on its disk and put it in the same location in RAM memory and executed it. Because of the very limited amount of RAM, those programs ran very slow.

At that time, it was not unreasonable for you to start a program and then have lunch and hope it was finished after lunch. Not all computers can execute firmware from RAM. The ARM processors such as the STM32H743 do have that capability. Because the RAM space of the STM32H743 is so large, we have lots of space for program overlays.

The next issue is speed. We know the M17 protocol works at 168 MIPS on the STM32F405. The STM32H743 executes at a speed nearly three times faster and sometimes over three times faster because of its extended instruction set. Therefore, I believe that chip will do all the protocols with speed to spare.

The only roadblock is software. What makes this project feasible is the fact that almost all the firmware we need has already been done on the MMDVM. The MMDVM is open source so we should be able to complete this project in a reasonable amount of time.

Some of you might be thinking that there must be at least one other way of doing that. There are many other choices that might work and, on the surface, might be better. I will give some of those choices and explain why they were not chosen.

For those of you who are familiar with the ARM architecture, might know you can run code memory directly from external serial flash memory. To do this you will need at least two flash memory chips. The problem with this is the speed of execution runs considerably slower and might be too slow for the application. We did not want to try it and find out months later that it did not work satisfactorily.

For those of you who kept up with the CS7000 project many years ago, know that we had the perfect hardware solution. It used a dual processor architecture from Texas Instrument. One processor was a super-fast floating-point DSP chip and the other processor was a very fast ARM chip. The radio has lots of RAM and Code memory on external chips. There were only two issues. The first issue was cost. It cost us about twice what the CS7000 M17 PLUS will cost to manufacturer. The second and most important reason was the dual processor architecture was too difficult to work with. Even with a little help from the radio manufacturer, it was beyond our capabilities. With a lot of help we might be able to finish it but at that time they were not willing to give us the help needed.

There was another practical consideration. To get the manufacturer to help us with this project, we wanted to minimize his effort. The design of this radio is almost identical to the radio he is currently selling.

Date: Mon, 30 Sep 2024 03:08:15 -0400 (EDT)
From: "Connect Systems Inc." 

CS7000 M17 and CS7000 M17 PLUS Status Report

We have two M17 products. The first one is called CS7000 M17 and the second one is called CS7000 M17 PLUS. The PLUS version is a CS7000 M17 on steroids.

We already have some individuals working on extending the capability of this radio for features not available in any other radio. I will give details in the near future.

We have currently shipped about 50 of the CS7000 M17 and the user reports are quite encouraging. We made 100 more and started to preload the M17 firmware to make it easier for our customers. In doing so we found a minor mistake in the battery level firmware and wanted to resolve the issue before they were put in our store and shipped.

The manufacturer isolated the problem and Silvano made a change. The manufacturer tested the new firmware and said it was fixed. When I get back to the office next Sunday, I will test it myself and then put them back in the store and ship them again.

I was supposed to get the CS7000 M17 PLUS production order shipped at the end of September. We already have a few samples. Before the production order is finished, the manufacturer wanted to make sure the DMR and M17 part was working. The manufacturer is responsible for the DMR part and Silvano will do the M17 part. The manufacturer said he will have the DMR part done in time. Silvano has not committed to a date at this time.

Just before the due date, the manufacturer said his engineer said the peripherals on the microprocessor is different from the previous microprocessor and is going to be difficult to implement.

It was my belief when I started this project that the two microprocessors are about the same except one has more memory and is about three times faster. I took a look at the differences between the two microprocessors and found that the first peripheral the manufacturer was complaining about (D/A Converter) was identical except the new part had more features that you could ignore.

The second peripheral I looked at (A/D Converter) looked about the same except there might be some minor differences that has to be accounted for. The old part has a resolution of up to 14 bits and the new part has a resolution of up to 16 bits. If that is the only issue, then there might have to be one instruction to compensate for the difference. I am not in a position now to carefully evaluate any changes between the two parts. Hopefully the two parts are identical except for more features that can be ignored.

If there are any programmers on this mailing list that can comment about the differences between the STM32F405 and the STM32H743 I would like to hear from you. Will the code written for the STM32F405 work on the STM32H743?

I still expect to start shipping the CS7000 M17 PLUS sometime in October. The manufacturer is currently on a holiday, so nothing is going to happen until he gets back on October 5. Silvano has the problem that his job is interfering with his hobby.

I will inform you of any changes to the status of the project as they occur.

Date: Tue, 3 Dec 2024 13:50:29 -0500 (EST)
From: "Connect Systems Inc."

Summary of Status of Firmware M17 is now working in the CS7000 M17 PLUS. The only thing left to complete is the integration of the DMR and M17 in the radio.
Will discuss that below. 

Integration of the DMR and the M17 

In theory the integration of the DMR and M17 is trivial. When the radio starts, pressing the SK2 (Side Button 2) allows you to either jump to the M17 firmware or the DMR firmware. They are completely independent of each other. 

It will probably take less than 20 firmware instructions to implement the logic. The logic has to be done in the DMR bootloader. It has to be done by the manufacturer because we do not have the source code of his program to modify or else we have to reverse engineer his firmware and do it ourselves, a difficult task. 

The manufacturer originally agreed to make the changes and just when we were ready to tie the two programs together, he decided that if he implements that feature, then we could modify the M17 code to read his code in the radio. 

The reason why the manufacturer is so paranoid about releasing his code is because the Chinese steal intellectual property not only from us, they also steal from their next door neighbors. If someone had his code, they could now manufacturer a radio in competition with him at a lower price because they did not have to pay for the development of the radio. The copyright laws are not very strong in China. However, even with the code and the schematics of the radio, it would cost over $100,000 to manufacture a new radio. Would you want to spend that type of money if you do not know how many radios you can sell? 

A few days ago, I sent out an email with a prize of a radio to the first two people who could unscramble his code so we can modify it. Adam Goldsmith, AD1AM was the first person to do it. USPS shows he received the radio yesterday. A few days ago I sent a few emails to the manufacturer along with the unencrypted code of his radio that anyone can now use to copy his radios. Basically telling him that what ever he does in the radio is meaningless because the amateur community does not need his radio to copy his code.

I then asked him: "do you want to play meaningless games to protect your firmware or sell radios?" He decide his goal was to sell radios. We will get the modified firmware tomorrow. 

Hopefully, we will not have any more problems and we can start shipping the radios late this week or at the latest the week after. 

Once we have the firmware and a way to load it into the radio, I have to actually load the new firmware into each radio. My estimate it will take between two to four days to load all the radios and ship them. So that means there will be between two and four days between shipping the first radio and shipping the last radio. We are doing it in order of when received the orders for the radios.