Hello David, please find below answers to your many questions. Le 16/06/2019 à 19:08, David Ranch a écrit : ID'ing (sending callsign) is of course only done in "NPR" protocol. I've not read your "part 97" rules. Let me know if it matches your local regulations; but if AREDN, DSTAR, C4F and DMR are OK with that, NPR should be OK also. No watchdog currently. Here in France, we use a "remote modem" in association with a R-Pi, for remote access. The R-Pi is programmed to reboot the modem once every day. I will see if it's possible to add a standalone and efficient "watchdog". I don't know if my microcontroller has such hardware feature, I will check. Of course, 2 clients can communicate together via the Master. But the Master or one client cannot wake-up another client. Only the Master has an "active/listening standby" mode, and can be waken-up by a client. Finally, if the Master is switched OFF, then the clients only send rare "connexion requests", which occupy in total less than 1% of the timeslots. I have not provided "mode 10", because my protocol is really not appropriate for such very low datarates. With my current protocol, you would have to wait a very long time in order for one clinet  to connect to the Master, because the "discovery slots" do not occur frequently. We are organizing sale to Europe. Today, I'm still not sure if we could sell to US. It would be a great help if someone could organize a sale in the US directly. The BOM is easy to provision, it's given in the documentation. I can help if you have question. Scanning is possible, the SI4463 has such feature. But I'm not sure I will program that. Like you say, SDR software already exist, and easier to use. And automatic channel selection will not match ham-radio needs. It could be possible... but difficult. My design is in the spirit of minimalism. At least, we could develop a "FDD" version, with the Master-repeater station being duplex, and the client stations being half duplex, like 2G/3G phones. But it will add a lot of complexity. I can add this feature to the "wish list", and see if people want it or not. It can be helpfull if you put an NPR Master on a tower which already has a 70cm repeater, full duplex with frequency split. Aggregating several channels : I will not program that, because I don't see the need. If you need more datarate, just use higher symbol rate! If your idea is to strictly respect the "56kBaud" rule of the FCC, then that's a non-sense in my opinion, too crazy. In my opinion, the "occupied radio bandwitdh" rule is much more important than the "Baudrate" rule. I don't see the meaning of a "baudrate" limitation. MTU is 1500, like with Ethernet. In order to be compatible with "lots of things" (IPv6, other IPv4 architectures, static IP, backbone links), I plan to add a "pure ethernet" mode in the following months: the radio protocol will carry "Ethernet frames" instead of currently "IPv4 packets". That's not possible. The Nucleo L432 board, which I currently use, is already the most powerfull with this "form factor". If I propose a new microcontroller, it would probably be directly integrated to the PCB (LQFP package), so PCB assembly should be made by "automatic PCB assembly" services, or by human with very good soldering skills. OK, thanks, I will do that. I plan to add that later.

David, I just answer you about 2 points below. Le 17/06/2019 à 18:38, David Ranch a écrit : The NPR protocol was initially designed for a "point to multipoint" topology. And it is good at it. It's was designed to be an "access" technology to Hamnet-AREDN networks. If the users switch on their "client modem" on demand, then the NPR network wakes-up on demand. NPR is currently not well designed for "backbone-point-to-point" topologies. I know it. OK, I could maybe add features later, but I have lots of work to do before. One question for you : on which condition do you think we could "wake-up" part of an IPv4 or Ethernet network? Protocols above the L2 or L3 (VoIP for example) are usually very chatty, and keep sending packets, even when no real user activity. You might be mistaken. The L432KC is 80MHz RAM_64kB Flash_256kB, whereas the F303K8 is 72MHz RAM_16kB Flash_64kB which is way too low for the NPR firmware. The L432KC is really the most powerfull for this form-factor, inside the STM32 offer.

I know that I will say the obvious, but if I get this right , there is a raspberry pi at each client and master. There is an easy way to set a batch file that can do a "ping" or other type of network activity said at any given time interval. That would keep a client alive till there is a way to fix this in the radio firmware itself. This could be a simple udp packet sent so that it wont even need a response back. A few bytes and it is done. Guillaume, why do you say that the npr radio's are bad as a back bone system? If you talk about time slots, would it be possible to do a kind of lock to a single mac or radio?the master and each use each ther specific time slots? That protocol make me think of the old token ring systems, ( IEEE 802.5 ) every one could ear every transmission on the network, there was no collision checks as every client or server had a token asigned to them. But if there was only 2 client or server on the same network, and the configuration was done properly, it was pretty fast for the time. Envoyé de mon iPad