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
You are here
NPR (New Packet Radio) Available
Sat, 10/26/2019 - 15:32
#1
K6AH
NPR (New Packet Radio) Available
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
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
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
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
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
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
Hello Paul,
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...
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
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
Guillaume:
Thank you very much for your reply, and for your huge contribution to the community!
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:
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.
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:
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
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
Guillaume:
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.
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.
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 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.
I do not believe raw Ethernet support is required for connecting AREDN via DtD or WAN:
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
"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
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
Guillaume:
Again, thank you for taking the time to consider our application and and understand the requirements.
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:
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:
-
- 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.
- 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.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.
I really like this idea, and it works for both configurations:
73 and thanks again,
- Paul, K3PGM
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
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 ?
Andre
Joe AE6XE
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?
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.
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.
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 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
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
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
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:
Challenges:
Approach:
Alternative that supports traditional LAN devices:
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
Andre, K6AH
- Paul, K3PGM
Andre
>> 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.
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
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
I did not notice a slip of paper with instructions in the box.
73,
- Paul, K3PGM
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
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).
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.
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.
One of the packages seems to be lost in transit, though. We will see.
They have offered a refund or sending another one. Of course I have asked for a new package.
Very responsive seller.
https://www.ebay.com/itm/NEW-70MHz-Bandpass-Filter-High-Performance-IF-Filter-SMA-Interface/113004483646?hash=item1a4f97943e:g:vCQAAOSwMM9bAkoD
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
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
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.
https://www.elekitsorparts.com/product/npr-70-modem-by-f4hdk-new-packet-radio-over-70cm-band-amateur-radio-packet-radio
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.
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 ?
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