You are here

NPR (New Packet Radio) Available

67 posts / 0 new
Last post
K6AH
K6AH's picture
NPR (New Packet Radio) Available

Just ordered a pair of F4HDK's NPR-70 70cm TCP/IP Data Modems (fully assembled for $80 ea) and DMR amplifiers ($140 ea) which I intend to use to gain access to the SoCal AREDN network from my house (it's in a bit of an RF hole). They come from China, so I expect 2-3 weeks delivery.  

https://www.elekitsorparts.com/product/npr-70-modem-by-f4hdk-new-packet-radio-over-70cm-band-amateur-radio-packet-radio 

Andre, K6AH
 

N3WTT
Will be following
I find this interesting let us know how it works?
F4HDK
New Packet Radio
Thank you Andre!
I'm the inventor of New Packet Radio (NPR).

There are lots of news about my project.
Reminder, all info is here: https://hackaday.io/project/164092

A Chinese partner is now selling modems, assembled or kits, world-wide.
Price is low : 80$ fully assembled, with aluminum enclosure.
https://www.elekitsorparts.com/product/npr-70

I have improved the firmware, it's more stable, and it now allows the optional "FDD mode" (Frequency Division Duplex).
With this feature, you can use the Master (=repeater) in duplex mode, with 2 modems (TX/RX) and a RF duplexer. The frequencies are different between uplink (from Clients to Master) and downlink (from Master to Clients). Clients are half duplex, with one single modem, switching very fast (300us) between uplink and downlink frequencies. The main goal is to put NPR master on tower where there is already a duplex repeater (FM or DMR or D-Star...), without interference between the 2 repeaters.
Check all the documentation on hackaday for more details : "Introduction", and "Advanced user guide".
The new firmware is also on hackaday of course.

Finally, I have written an article for "IEEE spectrum"; It's currently on the web, and it will be on the paper version in a few days. I hope it will bring some advertisement to my project, and to the modern amateur radio movement.
https://spectrum.ieee.org/geek-life/hands-on/build-a-longdistance-data-network-using-ham-radio

If you have any question, just ask me.

73,
Guillaume F4HDK
K6CCC
K6CCC's picture
Where will you be pointing?
Andre, just wondering where you will be pointing your NPR link?  One of my concerns (in general) is that 434 MHz (the frequency referenced in the ieee article) is heavily used for ATV in many areas.  Here in southern California, that frequency is used as an input for several ATV repeaters.
 
F4HDK
Frequency :
@K6CCC
Have you read the documentation on my hackaday page?  https://hackaday.io/project/164092
You should read at least the "Introduction" document, and then if you have enough time the "advanced user guide".

Of course, the frequency can be tuned in the whole range 420-450MHz.

Maybe the IEEE article is not clear, sorry. 434MHz is only the frequency for the ISM band.

73,
Guillaume F4HDK
K6CCC
K6CCC's picture
No, I had only read the ieee
No, I had only read the ieee article.  My concern is that a lot of the ISM devices are not at all frequency agile.  They are 434 or nothing.  One other question about these.  What is the bandwidth?  That is not mentioned in the ieee article.
 
F4HDK
please read the documentation
Once again, please read the documentation on the hackaday site.
There is lot of information there

https://hackaday.io/project/164092


You should read at least the "Introduction" document, and then if you have enough time the "advanced user guide".

If you don't find information you request, just ask me.

73,
Guillaume F4HDK
K9CQB
K9CQB's picture
We're doing it here as well in Northern Virginia
Andre, 
K-Jam (KE2N) and I each built 3 of these the hard way. Thank you for sending out the link for the new website that is selling both the kit ($69ea ) and the fully assembled version ($79ea), but the fully assembled version was bought out immediately. It will be in stock again in 2 weeks. 

I found a cheaper source for the TDMA amplifiers for only $90 on eBay:
AMP‑U25D - UHF (+DMR) Amplifier 400-480MHz, 20-40W Output 2-6W BTECH AMP T2 ($90)
https://www.ebay.com/itm/AMP-U25D-UHF-DMR-Amplifier-400-480MHz-20-40W-Ou...

I have not gotten my nodes installed yet. I am going to pair a Raspberry Pi with each of these modems to manage services. One of the slave models will also have a LoRa-mesh hat on it for future LoRa management connectivity. This node will also be connected to an AREDN 5GHz node. Here is a photo:

-Damon K9CQB
Image Attachments: 
K3PGM
K3PGM's picture
Ditto in Delaware

Andre:

Here in Delaware (AKA the Second Flattest State in the Union) we're very interested in doing something similar. I managed to order three of the NPR-70 modems to experiment with connecting two sites (one of them my house) to our mesh infrastructure. With flat terrain and 80-foot trees everywhere, practically everyone in Delaware is "in a bit of an RF hole" at SHF. In fact, to date our backbone sites outnumber our end users because making connections on any of the AREDN-supported bands has proven very difficult. If we could make some of those connections with NPR, I predict very rapid uptake of that technology here.

Unfortunately, I'm not sure how best to match the NPR networking model to the application. Implementing the "LAN" and "WAN" use cases described a few months ago by Joe AE6XE in another thread is straightforward, but it seems to me that some variant of his "DtdLINK" use case is what we really want, and I haven't quite worked out how to do that. The difficulties I see include the fact that the DtD interface has a statically assigned /8 address, which doesn't fit the NPR addressing model, and that any site with more than one node is going to have lots of redundant OLSR broadcasts that really shouldn't be flooding the NPR link.

You could, of course, just set up the NPR modems as WAN connections and open a tunnel across them, assuming you don't mind the extra overhead and can disable encryption, but there should be a better solution.

One approach might be to add, on just one node at each site, an additional virtual interface just for DtD over NPR, with its address assigned by DHCP from the NPR pool. Put that interface and the NPR modem on their own VLAN, and set a high link cost on that interface so it's only used if no better route is available. But that's just my first thought; perhaps there's a simpler way?

Thanks and 73,
Paul, K3PGM

F4HDK
NPR and AREDN

Hello Paul,

Unfortunately, I'm not sure how best to match the NPR networking model to the application. Implementing the "LAN" and "WAN" use cases described a few months ago by Joe AE6XE in another thread is straightforward, but it seems to me that some variant of his "DtdLINK" use case is what we really want, and I haven't quite worked out how to do that. The difficulties I see include the fact that the DtD interface has a statically assigned /8 address, which doesn't fit the NPR addressing model, and that any site with more than one node is going to have lots of redundant OLSR broadcasts that really shouldn't be flooding the NPR link.

I've not understood what DtdLink is, sorry.
Could you please discribe more precisely where do you think that there will be problems about NPR links inside an AREDN network?
My knowledge about AREDN is almost zero... I don't know the technical constraints of the AREDN.
Do you have a concise documentation?
There seems to be VLANS, OLSR, but I don't find a clear overview. Only user guides, which do not talk about the underlying details...

You could, of course, just set up the NPR modems as WAN connections and open
a tunnel across them, assuming you don't mind the extra overhead and can
disable encryption, but there should be a better solution.

In my opinion, NPR is mainly designed for "access" network, "last mile" (could be dozens of miles of course). Connexion from Client to Backbone.  What you call "endpoints" here :  https://arednmesh.readthedocs.io/en/latest/arednNetworkDesign/network_topology.html
Due to very limited datarate of NPR, you should be very careful about chatty protocols. Avoid usage of NPR in backbone. Avoid usage of VPN over NPR, etc...

Once again, if many people request it, I could develop a "full ethernet" mode, it would probably take a few months. But I do want to understand why you would need it.

About the ideas of Joe AE6XE (which I've not understood), I forgot to answer that currently, NPR does not provide "IPv4 broadcast", nor "multicast". Currently, it only carries IPv4 unicast trafic.

73,
Guillaume F4HDK
 

K9CQB
K9CQB's picture
"Full Ethernet" mode, please. It would bring more use cases.
Guillaume,
I would love to have a "full Ethernet" mode. There are several applications we would like to try that would require a bit more that just unicast traffic. We have a lot of highly capable network engineers involved in AREDN and many of them will think of all sorts of cool applications for you NPR if you have a "full Etherent" mode.
I have 3 of your modems and I haven't installed them yet, but I'm testing a lot of data stuff. I will absolutely buy 4-5 more NPR modems (the Funtronics version) once they are back in stock. I'll be buying the fully assembled version as I've already assembled 3 of these things and I think I'm well practiced in it. Here's the website I'm referring to where they are out of stock:
https://www.elekitsorparts.com/product/npr-70-modem-by-f4hdk-new-packet-radio-over-70cm-band-amateur-radio-packet-radio

-Damon K9CQB
K3PGM
K3PGM's picture
Guillaume:

Guillaume:

Thank you very much for your reply, and for your huge contribution to the community!

I don't know the technical constraints of the AREDN. Do you have a concise documentation? There seems to be VLANS, OLSR, but I don't find a clear overview. Only user guides, which do not talk about the underlying details...

One of the AREDN developers could do a better job of answering your question; I'm just a user. But I'll give it a try (and welcome corrections)...

AREDN is focused on emergency communications, with an emphasis on easy, rapid deployment in the field (at a disaster site, say, or an outdoor event such as a race). It is designed to be usable by people who know next to nothing about IP networking, and as such, must be almost entirely self-configuring. In theory, you just flash the firmware, put in your callsign, center frequency, and bandwidth, and you're on the air. The node itself does everything else, including assigning itself a few pieces of the 10.0.0.0/8 address space all AREDN nodes share.

Every AREDN node is a router with four logical interfaces:

  • The radio interface (usually 802.11n)
  • The LAN interface, to which the user connects local resources such as laptops, IP cameras, and VoIP phones
  • The Device-to-Device (DtD) interface, a wired link to other AREDN nodes that do not share a radio frequency
  • The WAN interface, which allows the node to act as a gateway from the mesh to the Internet when a local Internet connection is available

Most node hardware has only two physical interfaces (WiFi and Ethernet), so the LAN, DtD, and WAN logical interfaces appear as separate VLANs on the single Ethernet port. Which of these logical interfaces is in use on any particular node will depend upon the circumstances of its deployment.

If the WAN interface is connected, the node uses DHCP to get an address from the upstream gateway and then acts as a NAT gateway to the 10.0.0.0/8 address space that represents the entire mesh. The other three interfaces all have static addresses automatically derived from one of the node's MAC addresses, without reference to any external entity, since none is known to be available. Again, all these addresses are in the 10.0.0.0/8 space.

When Joe AE6XE described his "WAN use case", what he meant was using an NPR client as the upstream gateway for the WAN interface, with the NPR master somehow connected to the larger Internet.

On the LAN interface, the mesh node acts as a DHCP and dynamic-DNS server, handing out addresses from the small pool it reserved for itself out of the 10.0.0.0/8 mesh address space. In the normal configuration it does not provide NAT, so all LAN resources are visible from anywhere on the mesh. For example, a PC on one node's LAN can directly connect to an IP camera on another node;s LAN.

When Joe AE6XE described his "LAN use case", what he meant was placing an NPR master on the LAN of one AREDN node, and connecting one or more LAN resources (such as a PC or IP camera) to one or more remote NPR clients.

Finally, the radio and DtD interfaces both serve to connect nodes to one another. The nodes broadcast OLSR traffic on both interfaces, and olsrd organizes all the nodes that hear one another into a single mesh island. It is common, particularly at backbone sites, to have a number of AREDN nodes operating on different frequencies, all connected together on a common LAN via their DtD interfaces.

When Joe AE6XE described his "Dtdlink use case", what he meant was replacing a subset of those DtD connections with an NPR master and clients, so as to coalesce two or more mesh islands that would otherwise be out of range of one another. Now, I understand that this use case is emphatically not the one for which NPR was designed, but if it could somehow be shoehorned in, it would be of great interest to the AREDN community.

Again, the primary intent of AREDN is emergency communications. Sometimes, deployiing a mesh island in a small area (say, a race course) is enough, but in many cases, enabling meaningful emergency response means erecting a permanent mesh backbone over a large area and training and equipping volunteers to deploy to a field location, set up a local mesh, and connect that local mesh to the backbone for communications to emergency operations centers, hospitals, race organizers, etc.

It's the last part that's the problem: reaching the backbone from the field site. In an actual emergency one might have enough ham volunteers to station a whole chain of relay nodes between the site of the emergency and the nearest backbone site, but real emergencies, thankfully, are rare. In the meantime, it is crucial to motivate those volunteers to equip themselves and train with that equipment sufficiently frequently to maintain readiness. The best way to do that is to make it easy to connect mesh nodes from their own homes where they can integrate them into their normal amateur-radio activities.

In mountainous areas, that's easy: just put a node on your roof and point it at whichever peak has the local mesh relay. But the highest "peak" in Delaware is 134m above sea level, and yes, we do have a tower at that location, but the only ham who can see it directly lives 60m from the tower. Everyone else has at least 20 trees, or an office building, or a low hill in the way.

It is possible to connect two mesh islands via an encrypted tunnel over the Internet; that's how my house is connected. But that doesn't excite very many hams because there's no radio involved. We really need to be able to offer radio-based connections, even if they're slow.

Could you please describe more precisely where do you think that there will be problems about NPR links inside an AREDN network?

The natural way to connect small AREDN mesh islands would be by extending DtD links over some other transport such as NPR. The traffic on DtD links is essentially identical to that over the radio links: a combination of IPv4 unicast datagrams carrying user data between LAN resources and IPv4 broadcast datagrams carrying OLSR updates from the directly connected nodes. The problems I see are:

  • NPR doesn't currently handle IPv4 broadcasts, although I see that there is provision for them in the protocol. All the OLSR traffic is addressed to 10.255.255.255, and that is the single biggest difficulty.
  • All the DtD interfaces have statically assigned IPv4 addresses widely distributed throughout the 10.0.0.0/8 address space.
  • You only want to transport OLSR broadcasts from a single node at each site; the others are redundant.

So, putting an NPR master on the DtD network on the tower isn't going to work. As I suggested in my previous message, you could solve the address-space and redundant-broadcast problems by setting up a fifth logical interface on one of the mesh nodes at each site, making it a DtD-like interface with DHCP-assigned addresses and a high link cost to avoid unnecessary transits of the NPR network.

I'm not sure how we deal with the lack of support for IPv4 broadcasts.

Thanks and 73,
- Paul, K3PGM

F4HDK
Thank you Paul.
Thank you Paul.
I understand much better now.

Have you thought at which modulation/datarate you plan to use NPR? If you plan for example modulation 21, then you will have only 130kbps (sum of both uplink and downlink). That's very little compared to "several Mbps" provided by WiFi-like equipments.
In these conditions, do you really think that it is realistic to use NPR for WAN or DtD links?

I think that you should first give a try with NPR for "LAN access", and only after consider it for other types of links (WAN or DtD).

Other concerns:
 - the OLSR protocol can be quite chatty, if you plan to use NPR for DtD. Have you measured the overhead datarate of OLSR in a point to point DtD link? Such measurement are really necessary before considering DtD over (slow) NPR links.
 - DtD links are pure Ethernet links? Or do they carry VLANs?

If you are really interested about putting NPR links for DtD or WAN, then I could rapidly implement Ethernet, in a quick-and-dirty way, just for point to point topology. If you test it, and if you think that it's useful, then I could code a full Ethernet behavior with "point to multipoint" NPR networks, but it will take more time.

Finally, one question : how many Ethernet addresses would you like one "NPR network" to manage? 50 or 100 could be enough?

73,
Guillaume F4HDK
K3PGM
K3PGM's picture
Guillaume:

Guillaume:

If you plan for example modulation 21, then you will have only 130kbps (sum of both uplink and downlink). That's very little compared to "several Mbps" provided by WiFi-like equipments.
In these conditions, do you really think that it is realistic to use NPR for WAN or DtD links?

Yes, but in an emergency situation you can do a lot with that bandwidth. It's enough to, say, support a few simultaneous G.729 VoIP calls while other users update web forms and send the occasional still image. It's slow compared to WiFi, but not compared to Winlink over 1200 bit/second packet, or worse yet, spelling words one letter at a time over FM phone.

I think that you should first give a try with NPR for "LAN access", and only after consider it for other types of links (WAN or DtD).

We certainly will try that, and there are practical use cases for which that approach would excel, but it doesn't help the specific and important goal of motivating ham volunteers to acquire the hardware and skills needed to set up and maintain mesh networks for emergency communications. For that, they need to be able to connect to other hams as a matter of routine.

A tabletop exercise (such as connecting two 5.8 GHz nodes from one end of your basement to another) is a great way to get started, but if your interest is radio communications and the only way to connect from those nodes to another ham is through tunnel over the Internet, a sense of defeat quickly sets in. And so we have a lot of dejected would-be participants sitting around in this topographically challenging part of the country.

the OLSR protocol can be quite chatty, if you plan to use NPR for DtD. Have you measured the overhead datarate of OLSR in a point to point DtD link?

At this moment, there are 21 AREDN nodes online, with a total of 69 OLSR entries, on the mesh to which I am connected (through the aforementioned depressing Internet tunnel). The unidirectional data rate for OLSR traffic on one point-to-point link, including IPv4 overhead but not Ethernet overhead, is currently 5390 bits/sec. That's not bad by itself, but if we had several clients simultaneously connected via NPR, and the master node were rebroadcasting each client's OLSR packets to all the other clients, we'd have a problem. So perhaps it shouldn't do those rebroadcasts.

If the master did not rebroadcast the clients' OLSR packets, the resulting mesh routing tables would show the master-connected AREDN node as an intermediate hop between each pair of client-connected AREDN nodes. This routing is technically incorrect because traffic between two client-connected AREDN nodes would not actually transit the master-connected node, but it perhaps better represents the reality of the point-to-multipoint topology.

If the master were to transmit a frame to Client ID 0x7F (I know that's not yet implemented), would all the connected clients receive it simultaneously? If so, perhaps the only change necessary to NPR would be to recognize limited (255.255.255.255) or directed (e.g. 10.255.255.255) IP broadcast datagrams coming in on the Ethernet interface, and forward them to Client ID 0x7F on the radio interface.

Finally, we could further reduce the OLSR overhead simply by increasing the interface-specific intervals for OLSR messages.

DtD links are pure Ethernet links? Or do they carry VLANs?

DtD does not carry VLANs. AREDN nodes are pure IPv4 routers, and DtD links are simply IPv4 over Ethernet, with ARP. The only use AREDN makes of VLANs is to separate the LAN, WAN, and DtD traffic that must be stuffed into the single Ethernet port on the mesh device.

If you are really interested about putting NPR links for DtD or WAN, then I could rapidly implement Ethernet, in a quick-and-dirty way, just for point to point topology.

I do not believe raw Ethernet support is required for connecting AREDN via DtD or WAN:

  • The WAN use can be done today; the AREDN node would appear as a single device behind an NPR client, and everything else would happen via NAT. The use case for this configuration would be providing Internet connectivity to a single mesh island at a remote location.
  • For a real deployment, the DtD use case would require the limited implementation of IP broadcast described above.
  • For initial testing, we could work around the lack of broadcasts in NPR by configuring the NPR-connected AREDN nodes to use hardcoded unicast addresses for outgoing OLSR traffic. That approach doesn't work in the general case, but it's a quick way to test feasibility.
  • Increasing the interval between OLSR transmissions on NPR links would allow larger networks. Because NPR-connected mesh islands are unlikely to hop rapidly between different NPR networks, a slower update rate should not impact mesh stability.
  • I'd rather not pay for the overhead of Ethernet framing on the air.

So, my vote for the next NPR feature would be limited IP broadcast support, assuming the approach I outlined above is feasible. I can think of a number of fun things to do with Ethernet-over-NPR, but I currently see it as a lower priority.

Thanks and 73,
- Paul, K3PGM

AE6XE
AE6XE's picture
"my vote for the next NPR

"my vote for the next NPR feature would be limited IP broadcast support, assuming the approach I outlined above is feasible.".

Ditto.

This would support the AREDN dtdlink scenario  on limited size mesh networks.   At some point, with too many nodes on the AREDN network, the OLSR traffic would not leave enough bandwidth for applications to work (mesh chat, etc.).

Joe AE6XE
F4HDK
AREDN : automatic IP assignment inside DtD?

Before trying to implement Ethernet or IPv4 Broadcast, I need to understand the DtD more in details.
How are IP "automatically assigned" in DtD link? (You tell me that the network auto configures itself).
Does it matches the very-specific NPR behavior?

I really insist : the "LAN" usage of NPR is probably the most promising. 2.4GHz or 5.6GHz for backbone (with dozens of Mbps), and 430MHz for "users access". That's what we are doing here in Europe.
The "NPR-client" are already almost auto configurable regarding IP address aspects. If the AREDN router to which an NPR-Master is attached could automatically configure (via scripts) the NPR-Master, then it would probably match your request of using it (the Master) by low-skilled OMs.

73,
Guillaume F4HDK

K3PGM
K3PGM's picture
Re: AREDN : automatic IP assignment inside DtD?

Guillaume:

Again, thank you for taking the time to consider our application and and understand the requirements.
 

How are IP "automatically assigned" in DtD link? (You tell me that the network auto configures itself). Does it matches the very-specific NPR behavior?

Currently, DtD interface addresses are derived by a mathematical transformation on one of the AREDN node's MAC addresses. The resulting IP address can be anywhere in the 10.0.0.0/8 space. Clearly, this addressing scheme is not compatible with NPR. But that's OK, because that's not the DtD interface I propose we use with NPR.

Instead, we would create a second DtD interface on one AREDN node at each site; that interface would be dedicated to connecting to the NPR modem. The first DtD interface would retain its existing function of linking to other AREDN nodes at the site, and would not connect to the NPR modem.

The IP address of the second DtD interface would be assigned via DHCP, for compatibility with NPR:

  • At a client site, the client NPR modem would be configured with client_req_size=1, and the modem would hand out its one address to the second DtD interface of the directly attached AREDN node.
  • At the master site, the second DtD interface would again be directly connected to the master NPR modem. Because the master modem is not a DHCP server, the DtD interface address would be either statically configured or assigned by another DHCP server at the site.

 

I really insist : the "LAN" usage of NPR is probably the most promising.

You're right. I agree that the LAN-over-NPR configuration would yield the best performance for the end user. We will certainly experiment with this configuration,and happily deploy it wherever it fits.

Nevertheless, we also need the DtD-over-NPR configuration, even if it performs substantially worse, for two specific use cases:

  1. Training and experimentation: a ham's QTH hosts a multi-node mesh island so that ham can experiment with mesh configurations, test new hardware, develop a mesh go-kit, etc. That island also needs access to servers on the larger mesh, which is not within line of sight.

    • Real-world example: I currently have three AREDN nodes on line at my QTH, and half a dozen more on the shelf waiting for other experiments. Currently, I use an Internet tunnel to connect to the rest of the mesh.
    • How NPR would help: I would no longer be dependent upon my Internet connection, and that of the ham at the other end of the tunnel, both being up in order for me to run my own experiments as well as administer the rest of the mesh. Also, Internet tunnels are not ham radio.
  2. Backup connectivity: a mesh island in the field can lose its high-speed connection to the backbone, and thus needs a backup, even if it's slow.
    • Real-world example: At our Field Day site this year, we used a 3G cellular modem to maintain mesh connectivity when the 900 MHz mesh link went offline because of high background noise at the other end.
    • How NPR would help: We wouldn't have had to pay $60 in data charges, or explain to visitors why we were using a cellular modem as part of a ham-radio readiness exercise.
Again, I know that this isn't the use case for which NPR was designed, and performance issues are likely. But I'm convinced a lot of hams in this area, at least, will want to try it. Being able to have your own nodes on the mesh network is fundamentally different, and for many hams more exciting, than connecting their laptops to someone else's network.
 

The "NPR-client" are already almost auto configurable regarding IP address aspects. If the AREDN router to which an NPR-Master is attached could automatically configure (via scripts) the NPR-Master, then it would probably match your request of using it (the Master) by low-skilled OMs.

I really like this idea, and it works for both configurations:

  • For the LAN use case, the AREDN node could emit commands that would configure the NPR master modem to use a portion of that node's LAN address space.
  • For the DtD use case, the AREDN node at the master end could emit commands that would configure the NPR master modem to use a range of addresses adjacent to the statically configured address of the second DtD interface.


73 and thanks again,
- Paul, K3PGM

K9CQB
K9CQB's picture
Great use cases. We are in the same situation.
Paul,
I concur with the requirement of your 2 use cases. A lot of my buddies here in Northern Virginia and I are in the same situation. Where we would use the NPR to connect a 'small-ish' mesh island to the rest of the network.

-Damon K9CQB
KE2N
KE2N's picture
DtD traffic

I have a hunch that the OLSR traffic across the DtD link will be enough to totally swamp a 56 k link.  Does anybody have a measure of what typically flows across a DtD connection between two mesh-lets ?

K6AH
K6AH's picture
Only for small networks
Ken, the proposed use case is only for small networks.  It's usefulness will diminish as the network grows.

Andre
AE6XE
AE6XE's picture
On the southern CA network
On the southern CA network with typically 400+ mesh nodes, I receive about 9 OLSR packets per second at ~1500 byte packet size.   Thus about  13,500 bytes per second or 108kbps.   on a 10MHz channel under 802.11n at slowest possible rate of 3Mbps, this is only 3.6% of the time OLSR is consuming the channel (then my node is transmitting back another ~2 packets a second, so < 5% total channel time).    For running applications on the AREDN network, this OLSR time is not consequential.    An NPR link would be saturated and not able to do any usefull applications.   However, if the mesh size was  somewhere < 100,  an NPR link would start getting in the ballpark of functional (to use meshchat and other low volume traffic apps).

Joe AE6XE
F4HDK
ARP-proxy and routing are not compatible

Hello,

I think we were totally wrong focusing on the problem of broadcasting routing packets within a DtD link over NPR.
The main problem is not "routing OLSR packets"; the main problem is about forwarding "traffic packets". I will explain.

L3 IPv4 routing cannot work at all with ARP-Proxy in the middle. You cannot put routers at both ends of an ARP-Proxy, it will never work.
An ARP proxy totally puts to trash the destination Ethernet address of an incoming ethernet frame. The NPR client (which is ARP-Proxy) can only forward IP packet to its ethernet interface if it founds the destination MAC address (from the destination IP) via ARP, therefore only if the destination IP is "seen" directly by the ethernet interface (no router in the middle).

You just cannot put a router at the "client" side of an NPR network! (of course, you could put a NAT router, but that's not how AREDN works, and what AREDN needs). The "client NPR modem" (which is ARP proxy) will try to find MAC address of the destination IP address (via ARP), but it is not on the same ethernet-network/segment so nobody will answer! The "client NPR modem" will also never find the MAC address of the "next router", because it just doesn't know the IP of the next router. It only knows the destination IP address of a "traffic" IPv4 packet.
And at Master side, you can only put a single router which carries the "default route".

The only way to handle traffic between 2 standard routers (wired via Ethernet) is to handle Ethernet. Doing something else would be, in my opinion, very messy, and very difficult to debug for users/sysadmin.

At "short term", I can propose a very simple implementation: An NPR network will only forward all Ethernet traffic, from clients to Master and vice versa. Ignoring the destination and source MAC addresses. In this way, you will only handle traffic between Master and Clients; you will not be able to handle direct traffic between 2 NPR-clients. Maybe the AREDN router at the Master side can do it, I don't know. This is a "quick and dirty" solution, but I think it's enough for starting to work/test.
Are you OK with that?

For "long term", I will implement Ethernet-MAC address routing (like a switch). But I need to know how many MAC addresses max you plan to have in an ethernet segment (with NPR network in the middle). 30? 60? 100?

K3PGM
K3PGM's picture
Re: ARP-proxy and routing are not compatible

Guillaume:

Yes, you're right. Another way to say it is: because NPR uses a point-to-multipoint architecture, but has no routing information, it must depend upon the next-hop routing decisions made by the directly connected routers. The Ethernet destination address is, indeed, the most natural way to convey those decisions on an Ethernet link. Alternative pure-IP solutions include IP source routing (LSRR) or IP-IP encapsulation (tunneling), but those approaches are awkward and would require additional support in the AREDN nodes.
 

At "short term", I can propose a very simple implementation: An NPR network will only forward all Ethernet traffic, from clients to Master and vice versa. Ignoring the destination and source MAC addresses. In this way, you will only handle traffic between Master and Clients; you will not be able to handle direct traffic between 2 NPR-clients. Maybe the AREDN router at the Master side can do it, I don't know.

Well, the client-to-master traffic would work, and yes, the AREDN router at the master end would correctly route the traffic between client nodes. But if "ignoring the destination and source MAC addresses" means you would effectively treat all master transmissions as broadcasts, I think we would get broadcast amplification (self-inflicted Smurf attack) if we have more than one client.

Through OLSR, the node at the master end would learn all of the client routes, and the nodes at the client ends would learn that the node at the master end is the next-hop route for everything not behind that client node. One of the characteristics that distinguishes mesh routing from normal IP routing is that routing a packet out the same interface on which it came in is not considered an error. Thus, any client node that receives a datagram that should have gone to a different client node will dutifully forward that datagram back to the master node, which would then broadcast it again.
 

This is a "quick and dirty" solution, but I think it's enough for starting to work/test. Are you OK with that?

Yes, it's certainly good enough to test with a single client.

I would also prefer that you not strip the VLAN tag. Even though only traffic from a single VLAN would be present, retaining the tag means we need not un-tag and then re-tag the traffic at each end to get it into the AREDN node.
 

For "long term", I will implement Ethernet-MAC address routing (like a switch). But I need to know how many MAC addresses max you plan to have in an ethernet segment (with NPR network in the middle). 30? 60? 100?

For the AREDN DtD use case we only need 9 MAC addresses (master + 7 clients + broadcast) because we would arrange for the NPR-specific DtD VLAN to be isolated from other traffic at each site. And like WiFi, you could treat all multicasts as broadcasts.

One nice feature would be a configuration option that allows you to specify a single VLAN tag to forward; all traffic not having that specific VLAN tag would be dropped. That way, installations with just one AREDN node could put the node, NPR modem, and local resources all on an unmanaged switch. You could also construct a relay station consisting of one AREDN node, one NPR modem, a power supply, some cables, and an antenna.

Thanks and 73,
- Paul, K3PGM

K9CQB
K9CQB's picture
Shall I send you a few AREDN nodes?
F4HDK,
Do you need a couple AREDN nodes? If you had 2 nodes of one band, 2.4GHZ for example, that were linked via RF with one of them connected to a NPR-Master running 400MHz RF to an NPR-Client, then a 5GHz node connected to that client NPR, and a second 5GHz node across the room linked via 5GHz RF, you could experiment a lot with AREDN interconnectivity. 
Just let me know how I can help.

-Damon K9CQB
F4HDK
Thanks, but not enough free time
Thanks Damon for the proposal.
I won't have time to test NPR in all possible use cases. I let you (the AREDN community) test that, and give me feedback.
If I implement the "raw Ethernet over NPR" feature, then it will very probably work with AREDN DtD, with the mentioned limitations (datarate).

I don't know when I will code this feature. I will let you know.

73,
Guillaume F4HDK
K3PGM
K3PGM's picture
DtD over NPR-70 using IP-IP encapsulation?

In the absence of an NPR version that passes raw Ethernet, it occurred to me that we could also achieve DtD linking over NPR using IP-IP encapsulation, with similar overhead (a 20-byte outer IP header vs 18 bytes of Ethernet header + FCS). IP-IP encapsulation has the lowest overhead, both in space and time, of the commonly used Layer 3 tunneling protocols, and its major limitations (no security, no multicast) are irrelevant in this application.

So, I thought I'd give it a try. Unfortunately, while the necessary kernel modules appear to be present in the current AREDN builds, the "ip tunnel" command is missing (it was available in older firmware). I tried installing docker and building my own version, but so far I haven't been able to make it successfully all the way through the build process.

Perhaps someone with a working build environment could make a version with "ip tunnel" support compiled into busybox?

In the meantime, here's what I'm thinking. Please let me know if I've gone astray somewhere:

Assumptions:

  • We want to be able to achieve DtD linking using the existing NPR-70 firmware.
  • The master NPR modem is collocated with a node on the main mesh; client NPR modems are collocated with a mesh node in each disconnected mesh island.
  • Tunnels will be transient, appearing when an operator at a mesh-island node desires one. A mesh may have multiple NPR links, but there are no routing loops that include an NPR link.
  • We want to limit the OLSR traffic to a lesser fraction of the NPR link bandwidth.
  • Simultaneous support for the existing ability to use NPR-70 to link LAN resources to a remote AREDN node would be nice, but is not a requirement.

Challenges:

  • Client addressing is unpredictable because it depends upon the order in which clients connect to the master.
  • The client NPR modem must be prevented from capturing mesh LAN resources via DHCP.
  • The W5500 chip in the NPR modem does not support VLAN tags except in MACRAW mode, which precludes all on-chip protocol processing.

Approach:

  • The NPR master modem would either occupy a subset of the LAN addresses on the collocated mesh node, or be on a separate subnet associated with a new virtual Ethernet interface. In the latter case, because the NPR modem does not support VLAN tags, they would have to be stripped either by an external switch or the internal switch in mesh nodes so equipped.
  • The NPR client modem must be on a subnet separate from the collocated mesh node's LAN, so that the mesh node can obtain an address from the NPR DHCP server without losing control of addressing on the mesh LAN. The WAN interface could be used if not otherwise in use, but creating a new virtual Ethernet interface might be a better approach. Either way, the VLAN tags must again be stripped on the port connected to the NPR modem.
  • The mesh node collocated with the NPR master modem has an IP-IP tunnel interface preconfigured for each client address expected to be handed out to a remote mesh island.
  • Each mesh node collocated with a client modem has a single IP-IP tunnel interface preconfigured with the static address of the master node.
  • On all NPR-connected mesh nodes, olsrd.conf includes an interface-specific block for all the IP-IP tunnel interfaces, specifying a much longer (and ideally user-configurable) interval for all the message types. The interval would be chosen based on the expected size of the unified mesh. The traditional node interfaces, including any tunnels managed by vtund, would retain their shorter transmission intervals. Under the assumption that there are no routing loops that include an NPR link, the slower update rate should not cause routing instability.
  • The client modems will be configured to request a single IP address. When the client connects, the connected interface on the collocated mesh node will get that address via DHCP and the tunnel will be complete. OLSR traffic will then flow (slowly) and routes will be learned (eventually). Also, upon connection the client modem momentarily drops the Ethernet link to force the connected device into immediate DHCP negotiation; a mesh node with an internal switch, which would allow direct connection to the client modem, might be able to detect the state change on the switch port and thus accelerate establishment of the mesh link.

Alternative that supports traditional LAN devices:

  • The above approach assumes that the NPR master is supporting only mesh DtD links. One way, albeit rather clunky, to support a mixture of DtD links and traditional LAN devices would be to connect the master modem on the mesh node's LAN rather than a separate virtual interface, and configure the master modem with a larger address range and all the client modems to request a larger, and identical, number of IP addresses (say, two or three). The tunnel interfaces on the master-connected mesh node would then be configured with every second or third LAN address as the remote endpoint.
  • At the client end, the mesh node and the traditional LAN devices would all be on the same subnet. The first device to perform a DHCP negotiation would get the address that is the DtD tunnel endpoint, while the latecomers would become regular devices on the master-connected mesh LAN.
  • Did I say "rather clunky"? OK, it's really clunky. And it wastes a lot of address space. But if you really need that feature, it's an approach.

As I say, I haven't tried any of the above, although I'd like to. Does it sound workable? What am I missing?

Thanks and 73,
- Paul, K3PGM

K6AH
K6AH's picture
CBP Delay...
Argh!  It appears Customs has my shipment of NPR radios.  The amplifiers I ordered sailed right through.  I've been told by Customs that holds can take up to 90 business days to inspect and clear.  Not a lot I can do in the mean time.  I'd be interested in hearing comments from others who have ordered these from www.elekitsorparts in China.

Andre, K6AH
 
K3PGM
K3PGM's picture
Probably the same state...
The 4PX tracking information for mine has read, "Shipment arrived at airport of destination country" for almost a week. It's possible that they just stopped tracking it at that point, or it might be the same situation as yours. Sigh...

- Paul, K3PGM
K6AH
K6AH's picture
I'm beginning to wonder if...
ours might be the first NPR-70 devices to cross customs.  They could be checking everything from contraband to FCC type-approvals... the latter strikes me as a potentially major problem.  They call it a "modem" but it's really a transceiver.

Andre
K6AH
K6AH's picture
Just released by CBP
The shipment status now indicates the package has been released to DHL.  So fears appear to be unfounded.  Should be here in 2-3 days.
 
K3PGM
K3PGM's picture
Re: Just released by CBP
Mine, too. As of this morning, it's in transit from DHL to USPS, so I might even see it this weekend. Yay!
KE2N
KE2N's picture
NPR on the bench

>> Maybe the moderator could start  a new thread for discussion of NPR usage with AREDN ?

anyway - mine arrived and, after a little head scratching, (rats I had to read some of the instructions) I have the pair talking to each other on the bench.  Setting up a meaningful data link test will require a little more head scratching.

basics (get the Assembly and Programming Guide and the Advanced User Guide)
1) download and install the required USB/serial driver on your PC
2) plug in the NPR USB connection - at appears as a removable drive (like an OpenSpot) 
3) download and install the required firmware update for the microcontroller
4) download the application .bin file and drop it into the removable drive mentioned above

Then you need to edit the configuration to put in your call sign, select a FCC-legal modulation and turn on the transmitter.
>> putty.exe works very well for a serial connection (which you will need at some point)

Note -> do not plug the unit into your home LAN.  It has a DHCP server that will start stealing all your devices and putting them on 192.168.0.x.

Attached PNG shows the close-in spectrum of the un-amplified signal running modulation 20. Looks fine to me. You will have to stay 100 kHz away from any FM activity and probably 200 kHz away from weak signal activity. Maybe more when an amplifier is added. (I note that the Spectrum Occupancy document on the web page is for modulation scheme 21 which has a 100 k symbol rate - this is in excess of present FCC regulations for data) and twice the width of what is shown below.

Image Attachments: 
F4HDK
modems programed from "elekitsorpars"?
Hello,
You say that you had to program/download the modems. Have you bought from elekitsorparts.com?
If yes, then the modems (or microcontroller board for kit version) should already have been already programed: Front-LED blinking at power on.
Please tell me if it's not the case. I will contact the shop rapidly, this is not normal. 

73, Guillaume F4HDK
 
KE2N
KE2N's picture
program

Yes - these are from Elekitsorparts company.

It's not possible for me to "unwind the clock".  But - as best I can recall - the pattern of flashing LED's (that happens when you power the unit up) did not happen with my units. And I believe the MCU firmware was not the latest version. 

The shipment comes with a slip of paper telling you to go to the "instructables.com" web site and read the introductory information there.  The first thing you must do is install the USB/serial driver, in any case. I just followed on from there.  AREDN users are quite used to putting in the latest firmware, as soon as they take something out of the box, so I did not find this unusual.

But my order may have been a special case.  It was originally an order for kits - which was delayed.  I was sent an offer to upgrade to assembled units, at a discounted price, and I accepted that.

73
Ken

K3PGM
K3PGM's picture
Mine came with the 2019_09_15 firmware
I just received three assembled units from Elekitsorparts. I've only plugged in one so far, but it claims to be running the NPR firmware version 2019_09_15.

I did not notice a slip of paper with instructions in the box.

73,
- Paul, K3PGM
KE2N
KE2N's picture
very good

So what I got was apparently a kit unit that they assembled for me (but did not program).  I don't mind as I saved some money and learned how to load the firmware in the bargain.

cheers
Ken
 

KE2N
KE2N's picture
with amp

The spectrum in the previous posting was a bit optimistic in that the modem was running at only 0.1 watts out and I was using a rubber duck antenna on the SA.  This picked up a lot of noise from devices on the workbench and obscured the noise floor (and signals down near the "foot"). 

The curve below shows what you see with the amplifier on and running at rated power RF_power 20 (0.5 watts into the amp).  The signal is coax-coupled into the SA with a directional coupler and attenuators.

So it's rather broad at the base of the signal and not unlike the curve published on the web site (divided by two).  So the good-neighbor "keep away" margins in my previous post probably need to be doubled (200 and 400 kHz).  If your neighbors are digital signals it is less of a problem.  

With the supplied VGC amplifier, I am measuring about 10 watts peak at the output of the amplifier, not the 20 watts claimed. 

Ken


(Measurements made with an HP8900C peak power meter and HP84811A sensor head).

(In the spectrum pictures, the yellow dots represent one-time max values caught during a scan taken over a period of time.  The green curve is an instantaneous trace of the signal caught at random).

Image Attachments: 
N4SV
NPR modem modes/operation

The NPR70 modems have optional modes of operation, "normal" and "remotely managed", what precisely are the functional differences of these modes?  It states a computer connected to the modem via USB is mandatory for the "remotely managed" mode, but this seems counter intuitive; wouldn't you want less hardware (to fail) at a remote site versus one in the local shack?  And it might be a big plus if the mode selection was available via switch or jumper change rather than surface mount solder/de-solder process, just a suggestion.  And FYI, as stated on the ELEKITS site the units are currently out of stock and unavailable till next week for assembled units.  I was going to order a couple but the option is unavailable currently.  However the NPR70 application does sound exciting, and for those of us who have fought our way thru trying to get a LOS connection of AREDN nodes at 2.4 GHz or above, only to fail completely because of trees, hills, buildings in the way, something in the 440 MHz range could really put us back in the ball game, HI.

F4HDK
NPR remote management
@N4SV: in order to understand the difference between Normal and "Remotely Manageable" hardware, I strongly suggest you to read the"advanced user guide" and "assembly and programming guide". If something is not clear, just ask me.

For "remotely manageable", you need a R-Pi wired all the time via USB to your (remote) NPR-modem, and the R-Pi handles the remote access via SSH.
Yes, I agree with you, this is not optimal. But there was no easy solution to accept SSH remote access with only the small microcontroller inside.
And furthermore, a separate R-Pi makes "Firmware update over the air" possible, without the need of complex internal loader functions.
Maybe a future hardware with a much more capable microcontroller will be able to do that. But it is probably a big software development, therefore that's really not sure we can do it rapidly.
EA2EKH
EA2EKH's picture
I have ordered two kits,
I have ordered two kits, looking forward to play with them. 

One of the packages seems to be lost in transit, though. We will see.
 
EA2EKH
EA2EKH's picture
Confirmed. My second order is
Confirmed. My second order is expected to be delivered today, while the first order (placed a week before) seemed to be lost. I have contacted the seller and they have confirmed that on the same date several packages were lost.

They have offered a refund or sending another one. Of course I have asked for a new package. 

Very responsive seller. 
 
k2viz
Intermod & Noisy environments
I've been playing with my pair of modems + 20 watt amplifiers for a week.  When located on a Comet GP-9 on my home 70' tower, the results are very impressive.  1-2 mile range with a whip-mobile antenna, up to 5 miles at high elevation points.    I moved the master-unit to a downtown highrise (310' above ground) with a Comet GP-6 antenna.  The results are instantly horrid.  The master is basically "deaf" to any mobile, or received with a high error-rate.  When I put the client modem on my tower (line-of-sight -- 9 miles), the client-modem receives the master with -60db RSSI and 0% error rate, the master-modem receives at near -60db RSSI with 10-20% error rate.  I suspect the issue is front-end overload/intermod.  Any suggestions for dealing in an urban environment?  I'm looking at a bandpass filter for 70cm.  
K6AH
K6AH's picture
Here are some inexpensive ones
KE2N
KE2N's picture
bandpass

For "high-rise" locations, cavity filters similar to what repeaters use are going to be necessary.  I have not yet tested my NPR units here but - in anticipation of this very problem - did buy a couple of these 7 inch diameter cavities from eBay ( ​Sinclair Technologies, C3037-2, C3037 Series UHF 4 Cavity Duplexer Multicoupler ) .  Seems the Canadians are moving stuff off 420 MHz.  There were 3 of these left as of just now.  These are a really good deal.  Note that the typical 450 MHz cavities seen on the surplus market will likely NOT tune all the way down to 425 MHz.  

If you share a site with 440 repeaters, I think it is likely you will also need notch cavities for the repeater output frequency, Hopefully the repeater owner will not require you to put in a notch at his receive frequency, but that would not be out of the question.  Commercial 450 MHz cavities could be used for these notches.

Note that the 20 watt amplifier talked about in this section has somewhat excessive receive gain (a lot more than the PIN diode T/R switch losses) and that may exacerbate the problem.  There is another (80 watt) Chinese amplifier on eBay that has closer to unity gain on the receive side. (BTW: it uses a Mitsubishi module that requires low drive levels and, in my tests, produces a lot more power than the 20 watt amp.  I have not tested it with a data signal however).

For less-demanding locations one of the OCI filters would be good. These would allow wider signals than a cavity, if we ever get the OK to go to higher data rates.  The advertized 440 filter can be re-tuned to the 420-430 pass band (mine - originally a DCI filter - required replacing one tuning screw with a longer one).  Ralph Olds would be happy to provide you with one pre-tuned to your desired frequency segment, I'm sure.

There are also some SAW device filters that are intended for ISM/IOT applications. These do not offer enough attenuation of the UHF repeater band for high locations - but are really cheap ... unfortunately you cannot transmit through these (10 mw limit). Only specific frequencies are available (ISM frequencies).

The lowest cost option at this frequency range would be a PCB-based hairpin filter.  I have not seen one for sale at 430 MHz, but if you are handy with PCB fabrication, details can be found at   http://www.w1ghz.org/filter/Recipes_for_Printed_Hairpin_Filters.pdf
 
GL
Ken

F4HDK
Hello Peter.

I've been playing with my pair of modems + 20 watt amplifiers for a week.  When located on a Comet GP-9 on my home 70' tower, the results are very impressive.  1-2 mile range with a whip-mobile antenna, up to 5 miles at high elevation points.    I moved the master-unit to a downtown highrise (310' above ground) with a Comet GP-6 antenna.  The results are instantly horrid.  The master is basically "deaf" to any mobile, or received with a high error-rate.  When I put the client modem on my tower (line-of-sight -- 9 miles), the client-modem receives the master with -60db RSSI and 0% error rate, the master-modem receives at near -60db RSSI with 10-20% error rate.  I suspect the issue is front-end overload/intermod.  Any suggestions for dealing in an urban environment?  I'm looking at a bandpass filter for 70cm.  

Hello Peter.
Which modulation parameter have you tested? "20" ? 21 ?
Which frequency?

For your test from the "downtown highrise"... On mobile/client side, have you used directional antennas?
Once again, it is mentioned in the documentation : "New Packet Radio" is not robust to multipath problems. Therefore in urban environment, you will not be able to use it as "mobile" with small omnidirectional antenna at client side.
NPR is not designed for standard mobile usage. Except for the modulation 20 probably.

73,
Guillaume F4HDK

k2viz
Corrected "fixed mobile"
F4HDK,

Sorry for the delay in response -- a directional antenna was used, it helped some.  When I mentioned "Mobile" it was a whip antenna used while parked/stationary.  Both modulation 20 and 21 were used with equal results. Frequency range was 439.500 to 440.200 for testing.

I suspect a multi-cavity bandpass filter will be required for hi-RF environments.  When I used the Master/Client pair in a known low/mid-tier noise environment, everything works as expected.
K6AH
K6AH's picture
These are back in stock at Elekitsorparts as of 12/23/19
kp4djt
This looks like a solution for DMR repeaters off network

I have been readiing this list, these devices look like a solution for DMR repeaters that have network access issues, too far from any MW access. Must look at this very hard as it could be a piece that makes some DMR happen in places where we have no network connectivity. 

kk4hpy
Confused about data throughput of NPR

I am trying to compare with packet radio speeds and old telephone modem speeds to understand how this can be used. 
I understand UHF packet radio can do 9600 bits per second half duplex.  How many bits per second of data throughput can this NPR do ?

K6AH
K6AH's picture
Visit the developer's site...
You can read all about it here: ​https://hackaday.io/project/164092-npr-new-packet-radio
 
ke6bxt
ke6bxt's picture
Just curious... what
Just curious... what frequency do you plan on operating it on?
I can remember trying to look for a frequency to operate the Kenwood VCH-1
https://www.kenwood.com/i/products/info/amateur/vch1.html

Plus there there is the ATV on 434MHz and Scrrba considerations
http://www.scrrba.org/BandPlans/420-440.pdf
http://www.scrrba.org/BandPlans/440-450.pdf

I have been thinking of buying a pair of these but before spending $440 I want to know that I can use them.
I am interested to hear how the testing goes (range/data rate/24/7 operation or ad-hock)

I have already heard from the ATV community that they are "receiving interference from mesh" to their 434 MHz input to Santiago ATV repeater. I am trying to get clarification on just what that means.

Pages

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer