My question is what is the recommended installation for the npr-70 to connect to an existing mesh network. Mesh network had the Class A 10.x.x.x network and my local NPR-70 repeater is using the class C 192.168.44.x network. I do have a VLAN switch. I would like to the mesh node to see the npr-70 and visa versus.
My question is what is the My question is what is the recommended installation for the npr-70 to connect to an existing mesh network. Mesh network had the Class A 10.x.x.x network and my local NPR-70 repeater is using the class C 192.168.44.x network. I do have a VLAN switch. I would like to the mesh node to see the npr-70 and visa versus.
Hello, and sorry for the very late reply, I only discover your question now.
I don't fully understand what you want to do. 2 possible ways to answer to your question:
If you want to plug PCs or R-Pi to both networks, then it's feasible but not easy to do. At least one of the 2 networks must be "static" (not 2 DHCP networks), and only 1 network should have a "default route". In this way, the PCs will have access to the 2 networks, but the 2 networks will remain totally independant.
If you want to "route" data between the 2 networks (NPR70 and AREDN), then you should read the "advanced user guide" of NPR70. Only the Master can be attached to a router. It's totally impossible at client side. I let David and Edouard determine if they want to have routing feature at Black mountain between AREDN and NPR70.
For "long haul" links (prefer those who've tried ~200 km, but I'll take any data I can get) what effective throughputs
have your links achieved? The IPv4 overhead can "eat into" the effective throughput.
My application: inter-island data exchange. Fetch files for subsequent broadcast on each island (via a different means).
Thanks!
Hello.
I'm Guillaume F4HDK the inventor designer of "NPR70".
I have not tested such long links, and I don't know if someone has done it. I would be very happy to have feedback from you about test with such distances.
But I have an important information for you : you have to understand that NPR70 is not "autoadaptative", unlike WiFi for example. So if you are too optimistic with your RF link budget, then it will not work at all. The system will not reduce by itself the datarate in order to adapt to the poor RF link quality.
So it's the responsibility of the "sysop" to select the right "modulation parameters" of the NPR70 network, depending on usage, depending on the quality of the RF links planned. For a reliable link, you should obtain an "error rate" of ~2% maxi.
The most robust modulation is "modulation 11" : 2FSK, 100kS/s.
For such low datarate, you should reduce the MTU to 750, refer to the documentation.
Of course, for such distance, you will have to use very directional Yaggi antennas, or even better Yaggi antenna stacks, in well chosen sites.
Hello Guillaume,
On Page 19 of the PDF: https://cdn.hackaday.io/files/1640927020512128/NPR70_introduction_EN_v3....
We need Modulation 01 for FCC Compliance, as we cannot occupy more than 100 kHz or have a basic data rate above 56,000 symbols per second. Modulation 0x11 does not work for us. Can you make this change and push it out as an update?
Also, I have used a GRE tunnel between two UBNT Edgerouter X devices to adjust the PMTU and avoid the restrictions of the WizNet W5500.
There is enough delay over the link that it is not suitable for VoIP.
You probably mean "modulation 10", instead of "modulation "01" : 2FSK, 50kS/s.
For the USA, you already have "modulation 20" which fits 100% with FCC regulations : 50kS/s (equivalent to baudrate, but probably do not apply), and 100kHz wide.
It is not enough for your application ?
Maybe you are answering to my comment above. Yes, modulation 11 (100kS/s 2FSK) is more robust than modulation 20 (50kS/s 4FSK), even if both have the same usable data-rate.
Modulation "10" (2FSK 50kS/s) would be more difficult to implement (not impossible) because the "multi frame time slot" will occur very rarely, and the protocol needs these slots in order to work properly.
Other topic : which "W5500 limitation" are you talking about? Can you please explain? If you think about the missing implementation of IPv4 broadcast and multicast, and the impossibility to have 2 IPv4 routers on the same NPR70 network, then it's not a limitation of the W5500, but a limitation of the NPR70 protocol itself.
For VoIP, I have not tested "modulation 20", sorry. I will let other OM answer.
Modulation 21 (and above) works "fine", with software which auto adapts their VoIP buffer when they detect a big jitter.
We need Modulation 01 for FCC Compliance, as we cannot occupy more than 100 kHz or have a basic data rate above 56,000 symbols per second. Modulation 0x11 does not work for us. Can you make this change and push it out as an update?
Also, I have used a GRE tunnel between two UBNT Edgerouter X devices to adjust the PMTU and avoid the restrictions of the WizNet W5500.
There is enough delay over the link that it is not suitable for VoIP.
There are other countries that do not operate like FCC in the USA. In Canada, we should at least be able to run VOIP as a bare minimum. Winlink Post Office would work as well.
In the Vancouver, BC area we have a few hams ( I hope more) that will get on the UHF NPR. I was wondering if someone has done a Youtube video for us none techie IT Hams.
New Packet Radio (NPR), increase range with multi-hops?
Hello/bonjour Guillaume F4HDK or other NPR users,
Is it possible to use an "intermediate" NPR terminal to re-transmit IP communication (to extend range), as described on attached diagram?
Thank you. Daniel VE2BAP, Quebec, Canada.
Hello Daniel,
What you imagine is not possible with NPR70, sorry.
NPR70 is only aimed to be used with a "point to multipoint" topology currently. With the "Master" having the physical interconnection to the "wider network" (Hamnet, AREDN, Internet).
If you really want such a topology with the current protocol / firmware, you could use a "transparent transponder" (70cm to 70cm) in the middle, and frequency offset at both Master and Client side. But it is a bad solution because it would double the frequency bandwidth usage.
Guillaume,
I am going to have to order two of these to try them out. How much work would be involved in producing a 900 Mhz device for use in the USA where we have much more bandwidth to play with. Though the propagation is not as good as 70cm it is much better than 2.4 or above. In my area we are starting to see islands of AREDN activity, but they will be isolated, and of course the tunnel concept is not what they are interested in. These radios could provide the initial links between these islands, and if they were 900Mhz the wide bandwidth would be a big win.
Of course as the spaces are filled in with 2.4 and 5.8Ghz devices we can move them to other locatons.
"These radios could provide the initial links between...islands"
"These radios could provide the initial links between [AREDN] islands"
I am wondering if:
"What you imagine is not possible with NPR70"
Does anyone have a working example of using NPR devices to link AREDN islands?
Is there sufficient bandwidth to maintain the maintenance data?
...maintenance and user data?
How much throughput is available?
How much throughput is available following USA FCC regulations?
Guillaume,
How much work would be involved in producing a 900 Mhz device for use in the USA where we have much more bandwidth to play with?
@kp4djt hello.
About 900MHz, you should first order some RF44630-F30 modules with the right frequencies. One version is centered at 915MHz. https://www.tindie.com/products/nicerf/rf4463f30-1w-wireless-transceiver-module/
You could also contact the "elekitsorparts" shop, in order to negotiate a NPR70 kit without the RF4463 module, or with the 915MHz one directly. I have no idea if it is possible.
As far as I know, unlike for 430MHz, there is no fast-switching DMR power amplifier available for 900MHz. Therefore, you will only have ~500mW from the NPR70 transceiver.
Another difficulty is of course to make a custom firmware. I can provide you an untested version. But I am pretty sure that it will not work from scratch. We usually have to debug, and mostly to change some timings, due to the reaction of the SI4463 being slightly different between frequency bands. If debug is too difficult "remotely", I may need to have my hands on a pair of 900MHz hardware.
Finally, a big warning : NPR70 does not transport transparent Ethernet. It will be difficult to use as a backbone AREDN link.
The AREDN full-mesh protocol transports several Ethernet VLANs, and also routing information (OSPF, I think) which use quite a lot of datarate for low-bandwidth links. Some OMs have measured 70kb/s without any traffic.
Difficult but not impossible. We could try to make an "Ethernet point to point" version of the firmware. Or maybe a tunnel over the NPR70 link (500kb/s, modulation 24).
NPR70 is better suited for "access = last mile", but why not using it (or a derivative) for low datarate backbone at higher frequencies...
I don't fully understand what you want to do. 2 possible ways to answer to your question:
If you want to plug PCs or R-Pi to both networks, then it's feasible but not easy to do. At least one of the 2 networks must be "static" (not 2 DHCP networks), and only 1 network should have a "default route". In this way, the PCs will have access to the 2 networks, but the 2 networks will remain totally independant.
If you want to "route" data between the 2 networks (NPR70 and AREDN), then you should read the "advanced user guide" of NPR70. Only the Master can be attached to a router. It's totally impossible at client side. I let David and Edouard determine if they want to have routing feature at Black mountain between AREDN and NPR70.
73,
Guillaume F4HDK
have your links achieved? The IPv4 overhead can "eat into" the effective throughput.
My application: inter-island data exchange. Fetch files for subsequent broadcast on each island (via a different means).
Thanks!
Hello.
I'm Guillaume F4HDK the inventor designer of "NPR70".
I have not tested such long links, and I don't know if someone has done it. I would be very happy to have feedback from you about test with such distances.
But I have an important information for you : you have to understand that NPR70 is not "autoadaptative", unlike WiFi for example. So if you are too optimistic with your RF link budget, then it will not work at all. The system will not reduce by itself the datarate in order to adapt to the poor RF link quality.
So it's the responsibility of the "sysop" to select the right "modulation parameters" of the NPR70 network, depending on usage, depending on the quality of the RF links planned. For a reliable link, you should obtain an "error rate" of ~2% maxi.
The most robust modulation is "modulation 11" : 2FSK, 100kS/s.
For such low datarate, you should reduce the MTU to 750, refer to the documentation.
Of course, for such distance, you will have to use very directional Yaggi antennas, or even better Yaggi antenna stacks, in well chosen sites.
73,
Guillaume F4HDK
You probably mean "modulation 10", instead of "modulation "01" : 2FSK, 50kS/s.
For the USA, you already have "modulation 20" which fits 100% with FCC regulations : 50kS/s (equivalent to baudrate, but probably do not apply), and 100kHz wide.
It is not enough for your application ?
Maybe you are answering to my comment above. Yes, modulation 11 (100kS/s 2FSK) is more robust than modulation 20 (50kS/s 4FSK), even if both have the same usable data-rate.
Modulation "10" (2FSK 50kS/s) would be more difficult to implement (not impossible) because the "multi frame time slot" will occur very rarely, and the protocol needs these slots in order to work properly.
Other topic : which "W5500 limitation" are you talking about? Can you please explain? If you think about the missing implementation of IPv4 broadcast and multicast, and the impossibility to have 2 IPv4 routers on the same NPR70 network, then it's not a limitation of the W5500, but a limitation of the NPR70 protocol itself.
For VoIP, I have not tested "modulation 20", sorry. I will let other OM answer.
Modulation 21 (and above) works "fine", with software which auto adapts their VoIP buffer when they detect a big jitter.
73,
Guillaume F4HDK
We need Modulation 01 for FCC Compliance, as we cannot occupy more than 100 kHz or have a basic data rate above 56,000 symbols per second. Modulation 0x11 does not work for us. Can you make this change and push it out as an update?
Also, I have used a GRE tunnel between two UBNT Edgerouter X devices to adjust the PMTU and avoid the restrictions of the WizNet W5500.
There is enough delay over the link that it is not suitable for VoIP.
There are other countries that do not operate like FCC in the USA. In Canada, we should at least be able to run VOIP as a bare minimum. Winlink Post Office would work as well.
73
Don va7qu/va7dgp
73
Don va7qu/va7dgp
Which version did you order and has that worked for you as expected, Normal or Remotely Managed?
Thanks,
Jim
W8ERW
Hello/bonjour Guillaume F4HDK or other NPR users,
Is it possible to use an "intermediate" NPR terminal to re-transmit IP communication (to extend range), as described on attached diagram?
Thank you. Daniel VE2BAP, Quebec, Canada.
Hello Daniel,
What you imagine is not possible with NPR70, sorry.
NPR70 is only aimed to be used with a "point to multipoint" topology currently. With the "Master" having the physical interconnection to the "wider network" (Hamnet, AREDN, Internet).
If you really want such a topology with the current protocol / firmware, you could use a "transparent transponder" (70cm to 70cm) in the middle, and frequency offset at both Master and Client side. But it is a bad solution because it would double the frequency bandwidth usage.
73,
Guillaume F4HDK
Guillaume,
I am going to have to order two of these to try them out. How much work would be involved in producing a 900 Mhz device for use in the USA where we have much more bandwidth to play with. Though the propagation is not as good as 70cm it is much better than 2.4 or above. In my area we are starting to see islands of AREDN activity, but they will be isolated, and of course the tunnel concept is not what they are interested in. These radios could provide the initial links between these islands, and if they were 900Mhz the wide bandwidth would be a big win.
Of course as the spaces are filled in with 2.4 and 5.8Ghz devices we can move them to other locatons.
"These radios could provide the initial links between [AREDN] islands"
I am wondering if:
"What you imagine is not possible with NPR70"
Does anyone have a working example of using NPR devices to link AREDN islands?
Is there sufficient bandwidth to maintain the maintenance data?
...maintenance and user data?
How much throughput is available?
How much throughput is available following USA FCC regulations?
@kp4djt hello.
About 900MHz, you should first order some RF44630-F30 modules with the right frequencies. One version is centered at 915MHz.
https://www.tindie.com/products/nicerf/rf4463f30-1w-wireless-transceiver-module/
You could also contact the "elekitsorparts" shop, in order to negotiate a NPR70 kit without the RF4463 module, or with the 915MHz one directly. I have no idea if it is possible.
As far as I know, unlike for 430MHz, there is no fast-switching DMR power amplifier available for 900MHz. Therefore, you will only have ~500mW from the NPR70 transceiver.
Another difficulty is of course to make a custom firmware. I can provide you an untested version. But I am pretty sure that it will not work from scratch. We usually have to debug, and mostly to change some timings, due to the reaction of the SI4463 being slightly different between frequency bands. If debug is too difficult "remotely", I may need to have my hands on a pair of 900MHz hardware.
Finally, a big warning : NPR70 does not transport transparent Ethernet. It will be difficult to use as a backbone AREDN link.
The AREDN full-mesh protocol transports several Ethernet VLANs, and also routing information (OSPF, I think) which use quite a lot of datarate for low-bandwidth links. Some OMs have measured 70kb/s without any traffic.
Difficult but not impossible. We could try to make an "Ethernet point to point" version of the firmware. Or maybe a tunnel over the NPR70 link (500kb/s, modulation 24).
NPR70 is better suited for "access = last mile", but why not using it (or a derivative) for low datarate backbone at higher frequencies...
To be discussed further.
73,
Guillaume F4HDK
Pages