Hello.
I have updated the firmware of my NPR (New Packet Radio) project with 2 expected features, mainly for America: * New modulations (11, 12, 20, 21) for lower datarates, lower bandwidth. Symbol rates: 56kS/s (complies with FCC) and 120kS/s. You now have the choice between 9 modulation parameters, in order to adapt to lots of situations and needs. * Frequency range extended to 420-450MHz instead of previously 430-440MHz
I have updated all the documentation accordingly. https://hackaday.io/project/164092-npr-new-packet-radio/
Several people here expected these features. I hope you will enjoy it!
73, Guillaume F4HDK
A big thank you for that effort. This will surely start a new boom in "packet radio" in north America. I for one will push to implement the fastest links to our audio links back bones that is all in uhf for our emergency net . That way we will work in Voip rather then analog voice opening the way to many more service at the same time .
Télécharger Outlook pour Androidhttps://aka.ms/ghei36
________________________________ From: 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org on behalf of f4hdk f4hdk@free.fr Sent: Sunday, June 16, 2019 9:30:29 AM To: 44net@mailman.ampr.org Subject: [44net] NPR (New Packet Radio) : new firmware with 56kBaud and 120kBaud
Hello.
I have updated the firmware of my NPR (New Packet Radio) project with 2 expected features, mainly for America: * New modulations (11, 12, 20, 21) for lower datarates, lower bandwidth. Symbol rates: 56kS/s (complies with FCC) and 120kS/s. You now have the choice between 9 modulation parameters, in order to adapt to lots of situations and needs. * Frequency range extended to 420-450MHz instead of previously 430-440MHz
I have updated all the documentation accordingly. https://hackaday.io/project/164092-npr-new-packet-radio/
Several people here expected these features. I hope you will enjoy it!
73, Guillaume F4HDK _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Hello Guillaume,
This is fantastic news and thank you for working on this to allow for other regions to give it a try! Few questions if I may now that this is a reality to try:
- I see in the advanced guide that the system "IDs" itself every 2-6 seconds but what mode is that done in. In line with the symbol and spectrum limitations that the US amateurs have to deal with, IDing is also something to deal with. Is your system able to send non-NPR transmissions? http://www.arrl.org/part-97-text --> 97.119 Station identification . There is some discussion about this on the Hackaday comments section but there doesn't seem to be a conclusion about it.
- In the current firmware, I don't see any mention of a watchdog if the system crashes. Is it possible to add one?
- I see in the docs and videos the details about client to master but with this design, can say client #1 transfer data to client #2 via the master? Can client #1 automatically wake up client #2 and send data (assuming there is an IP server to connect to?
- Your advanced document mentions that due to weakness in the FEC algorithm, maybe using modes "11, 20, or 21". I see there isn't any mode "10" for the 56kS/s symbol signaling rate. Is this a limitation of the modem chip?
- Your Introduction PPT mentions a upcoming kit. Any ETA and cost on that? On the Hackaday page, you mention you would ship to the EU but does that mean you WON'T ship to the US? Making at least the PCBs, sheet metal and a parts BOM would be a huge help for us in the US.
- Interference on 433Mhz is always going to be a challenge but do you think it would be possible to add a "scanning" feature to the NPR system so it could go out and listen to X frequencies for Y seconds and come back with a report if those frequencies are quiet? This is something that Wifi has had on it's "channels" and it can be hugely helpful. In an amateur radio deployment, I don't that we would ever want a auto-channel selection feature but being able to initially listen and pick a frequency would be a huge help. The only other option here would be for the operator to deploy an SDR and listen in.
- With the lower bandwidth design, do you think enhancements could be made to support full duplex using two radios? Aka.. each transmitter could use multiple time slots for higher performance? I do understand how that makes the overall setup a lot more complex.
- You mentioned that NPR doesn't support IPv6 which is ok for small deployments but there isn't any mention of MTU. I assume this system supports a RAW MTU of 1518 bytes but maybe it can support smaller or larger MTUs to better deal with the BER rate of the connection?
- I see on the Hackaday page that it looks like the expansion from 7 clients to 15 clients might need different hardware. Would it be a good idea to socket the STM board so the upgrades could be "plug and play"?
- I see you have email lists other community links posted on the Hackaday page. Would be good to add those links to the end of the Introduction PDF
- Maybe this Q&A and some of the other points from the Hackaday comments section would all be well suited to start a FAQ?
Anyway, thanks again for your efforts here and making it available to the world!
--David KI6ZHD
On 06/16/2019 06:30 AM, f4hdk wrote:
Hello.
I have updated the firmware of my NPR (New Packet Radio) project with 2 expected features, mainly for America:
- New modulations (11, 12, 20, 21) for lower datarates, lower
bandwidth. Symbol rates: 56kS/s (complies with FCC) and 120kS/s. You now have the choice between 9 modulation parameters, in order to adapt to lots of situations and needs.
- Frequency range extended to 420-450MHz instead of previously
430-440MHz
I have updated all the documentation accordingly. https://hackaday.io/project/164092-npr-new-packet-radio/
Several people here expected these features. I hope you will enjoy it!
73, Guillaume F4HDK _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Hello David, please find below answers to your many questions.
Le 16/06/2019 à 19:08, David Ranch a écrit :
- I see in the advanced guide that the system "IDs" itself every 2-6
seconds but what mode is that done in. In line with the symbol and spectrum limitations that the US amateurs have to deal with, IDing is also something to deal with. Is your system able to send non-NPR transmissions? http://www.arrl.org/part-97-text --> 97.119 Station identification . There is some discussion about this on the Hackaday comments section but there doesn't seem to be a conclusion about it.
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.
- In the current firmware, I don't see any mention of a watchdog if
the system crashes. Is it possible to add one?
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.
- I see in the docs and videos the details about client to master but
with this design, can say client #1 transfer data to client #2 via the master? Can client #1 automatically wake up client #2 and send data (assuming there is an IP server to connect to?
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.
- Your advanced document mentions that due to weakness in the FEC
algorithm, maybe using modes "11, 20, or 21". I see there isn't any mode "10" for the 56kS/s symbol signaling rate. Is this a limitation of the modem chip?
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.
- Your Introduction PPT mentions a upcoming kit. Any ETA and cost on
that? On the Hackaday page, you mention you would ship to the EU but does that mean you WON'T ship to the US? Making at least the PCBs, sheet metal and a parts BOM would be a huge help for us in the US.
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.
- Interference on 433Mhz is always going to be a challenge but do you
think it would be possible to add a "scanning" feature to the NPR system so it could go out and listen to X frequencies for Y seconds and come back with a report if those frequencies are quiet? This is something that Wifi has had on it's "channels" and it can be hugely helpful. In an amateur radio deployment, I don't that we would ever want a auto-channel selection feature but being able to initially listen and pick a frequency would be a huge help. The only other option here would be for the operator to deploy an SDR and listen in.
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.
- With the lower bandwidth design, do you think enhancements could be
made to support full duplex using two radios? Aka.. each transmitter could use multiple time slots for higher performance? I do understand how that makes the overall setup a lot more complex.
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.
- You mentioned that NPR doesn't support IPv6 which is ok for small
deployments but there isn't any mention of MTU. I assume this system supports a RAW MTU of 1518 bytes but maybe it can support smaller or larger MTUs to better deal with the BER rate of the connection?
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".
- I see on the Hackaday page that it looks like the expansion from 7
clients to 15 clients might need different hardware. Would it be a good idea to socket the STM board so the upgrades could be "plug and play"?
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.
- I see you have email lists other community links posted on the
Hackaday page. Would be good to add those links to the end of the Introduction PDF
OK, thanks, I will do that.
- Maybe this Q&A and some of the other points from the Hackaday
comments section would all be well suited to start a FAQ?
I plan to add that later.
Anyway, thanks again for your efforts here and making it available to the world!
--David KI6ZHD
On 06/16/2019 06:30 AM, f4hdk wrote:
Hello.
I have updated the firmware of my NPR (New Packet Radio) project with 2 expected features, mainly for America: * New modulations (11, 12, 20, 21) for lower datarates, lower bandwidth. Symbol rates: 56kS/s (complies with FCC) and 120kS/s. You now have the choice between 9 modulation parameters, in order to adapt to lots of situations and needs. * Frequency range extended to 420-450MHz instead of previously 430-440MHz
I have updated all the documentation accordingly. https://hackaday.io/project/164092-npr-new-packet-radio/
Several people here expected these features. I hope you will enjoy it!
73, Guillaume F4HDK _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Hello Guillaume,
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.
I'm not an expert on FCC Part 97 and I don't want to derail this conversation but I don't think some of these protocols are legally self-identifying.
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.
The Raspberry Pi has a watchdog to keep things going there but it would be interesting what your microcontroller can do. Is there any limit of how long a client radio can be in fast or slow mode?
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.
Hmmm.. not being able to wake a client seems to restrict a lot of utility here. If a station cannot wake remote clients (so called "East-West" traffic), it seems this system really only supports "North-South" traffic.
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'm not sure I understand your point here. If the Master, located on a mountain, is off.. doesn't that mean the system is offline since this system seems like it's designed purely around a strict client/server design. Maybe clients someday could act like adhoc masters for local simplex communications?
- Your advanced document mentions that due to weakness in the FEC
algorithm, maybe using modes "11, 20, or 21". I see there isn't any mode "10" for the 56kS/s symbol signaling rate. Is this a limitation of the modem chip?
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.
Ok. I was just wondering since it sounds like the protocol 10 mode might be more robust.
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.
I've sent you an email to your free.fr account.
- Interference on 433Mhz is always going to be a challenge but do you
think it would be possible to add a "scanning" feature to the NPR system so it could go out and listen to X frequencies for Y seconds and come back with a report if those frequencies are quiet? This is something that Wifi has had on it's "channels" and it can be hugely helpful. In an amateur radio deployment, I don't that we would ever want a auto-channel selection feature but being able to initially listen and pick a frequency would be a huge help. The only other option here would be for the operator to deploy an SDR and listen in.
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.
Ok.. though I think this could be a very important feature in the future. Of the many things I've learned from Amateur Radio is that nothing stays the same forever and interference is unpredictable. People might put up an SDR during an initial site survey to find a clear frequency but they won't leave it there. Having this feature could fill in the gaps...
- With the lower bandwidth design, do you think enhancements could be
made to support full duplex using two radios? Aka.. each transmitter could use multiple time slots for higher performance? I do understand how that makes the overall setup a lot more complex.
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.
Understood and I generally agree with you though having a full duplex system could let some stations run a "super fast" mode ( multiple timeslots ). This could compensate for the lame symbol rate issue we have from the FCC.
- You mentioned that NPR doesn't support IPv6 which is ok for small
deployments but there isn't any mention of MTU. I assume this system supports a RAW MTU of 1518 bytes but maybe it can support smaller or larger MTUs to better deal with the BER rate of the connection?
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".
Ok though that would add more overhead if you add in the Ethernet header to an IPv4 packet. Another thing I've learned in my networking career, maintain the support for a 1500 byte MTU. Anything less will result in a support nightmare.
That reminds me, on slide 18 of the Intro pdf doc talks about "usable data rate". Is this the payload rate after the raw RF signalling rate or is this the effective TCP/IP payload data rate? Adding a definition in the doc would be helpful.
- I see on the Hackaday page that it looks like the expansion from 7
clients to 15 clients might need different hardware. Would it be a good idea to socket the STM board so the upgrades could be "plug and play"?
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.
Ah, ok. Looking around, the Nucleo L432 board uses the STM32L432KC chip which looks to be a 24Mhz low power part. Seems something like the NUCLEO-F303K8 might be faster and also in the same form factor? I guess this ultimately comes down to cost of the BOM but hopefully the parts you've designed around will give the system some future upgrades.
--David
David, I just answer you about 2 points below.
Le 17/06/2019 à 18:38, David Ranch a écrit :
Hmmm.. not being able to wake a client seems to restrict a lot of utility here. If a station cannot wake remote clients (so called "East-West" traffic), it seems this system really only supports "North-South" traffic.
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.
Ah, ok. Looking around, the Nucleo L432 board uses the STM32L432KC chip which looks to be a 24Mhz low power part. Seems something like the NUCLEO-F303K8 might be faster and also in the same form factor? I guess this ultimately comes down to cost of the BOM but hopefully the parts you've designed around will give the system some future upgrades.
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.
Hello Guillaume,
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.
The question of how to wake up an L2 connection is an interesting one. My first thought would be to possibly send Ethernet frames with different flags, etc. I don't have one of your kits (yet) so I'm speculating a bit here but if the master has a list of all 7 clients and their MACs, you can begin to make it begin to act like an Ethernet switch. If a remote station is "registered" with the master (aka.. hard coded in), the master could track the last time it was heard from. If you have non-broadcast traffic for that remote station and it hasn't been recently heard, you could send these alternative "wake up" Ethernet frames. The remote client would have a setting that would allow for remote wake-up (default on) and if it heard these frames, it would wake up and talk to the master using regular IP Ethernet frames. The question here is if the STM32 boards expose some of these alternative Ethernet frames for you to make decisions on.
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.
Hmmm.. ok. I'm not that familar with the STM32 line so I apologize. I had been looking at some data sheets that showed some versions with more RAM, etc.
--David KI6ZHD
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
The rules no longer really specify how you must ID, like pre-1980's. Basically in this case you ID in the mode itself, just like D-Star, YSF etc, does.
If the digital code was unspecified (also allowed) you'd likely have to default to a CW ID.
§97.119 Station Identification
(b) The call sign must be transmitted with an emission authorized for the transmitting channel in one of the following ways:
(3) By a RTTY emission using a specified digital code when all or part of the communications are transmitted by a RTTY or data emission;
§97.309 RTTY and data emission codes.
(4) An amateur station transmitting a RTTY or data emission using a digital code specified in this paragraph may use any technique whose technical characteristics have been documented publicly, such as CLOVER, G-TOR, or PacTOR, for the purpose of facilitating communications.
On Mon, Jun 17, 2019 at 11:40 AM David Ranch amprgw@trinnet.net wrote:
I'm not an expert on FCC Part 97 and I don't want to derail this conversation but I don't think some of these protocols are legally self-identifying.
Hi Guillaume, and congratulations for your great work !
Le 16/06/2019 à 15:30, f4hdk a écrit :
I have updated the firmware of my NPR (New Packet Radio) project with 2 expected features, mainly for America:
Here's my personal wishlist : - Point-To-Point mode and L2 transport, which will better integrate into our TKNet topology as a backbone link. It would be a great solution to feed a high point for a D-Star or DMR repeater, to add redundant links between our high points (UHF can go where 5 GHz can not), and to reduce usage of Internet VPNs. - Split TX and RX frequencies, so that a NPR modem can live on a high point near to existing analog or digital repeaters
Thank you and congratulations again for your great work, and for providing it as open-source. I am sure lots of people will love it :-)
73 de TK1BI
-
David Ranch -
f4hdk -
pete M -
Steve L -
Toussaint OTTAVI