Hello,
I am Guillaume, callsign F4HDK, a french amateur-radio operator, and a hacker-maker. I would like to share with you my last project : NPR (New Packet Radio).
All documentation is provided here : https://hackaday.io/project/164092-npr-new-packet-radio
This solution can transport bi directional IP trafic over 70cm radio links, in a 'point to multipoint' topology, at datarate up to 500kbps. This can be used to increase the range of existing HSMM-Hamnet networks, at lower datarates. It's designed for "access", not backbone, and not designed for H24 use. Its is 100% open-source.
Do not hesitate to ask me questions about it. I hope it will interest some people here.
73, Guillaume F4HDK
Very cool Guillaume and thank you for posting! I'll have to dig into site more and send you some more questions.
Question 1: are you planning on offering any hardware kits or complete build of this hardware?
Question 2: do you think it's possible to lower the data rate to the point that omni-directional antennas would work decently well?
--David KI6ZHD
On 03/24/2019 01:05 AM, f4hdk wrote:
Hello,
I am Guillaume, callsign F4HDK, a french amateur-radio operator, and a hacker-maker. I would like to share with you my last project : NPR (New Packet Radio).
All documentation is provided here : https://hackaday.io/project/164092-npr-new-packet-radio
This solution can transport bi directional IP trafic over 70cm radio links, in a 'point to multipoint' topology, at datarate up to 500kbps. This can be used to increase the range of existing HSMM-Hamnet networks, at lower datarates. It's designed for "access", not backbone, and not designed for H24 use. Its is 100% open-source.
Do not hesitate to ask me questions about it. I hope it will interest some people here.
Thanks David!
Answer 1 : I will not provide kits outside Europe (where I live), it would be too difficult, sorry. But I can help someone who wants to organize a "group order", and who wants to sell kits in the US.
Answer 2 : In order to achieve links with omnidirectional antennas, you have to lower the datarate drastically. In order to do so, I would need to change lots and lots of things in my protocol, which is not designed for such low datarates. Therefore, I will not make such a development, sorry.
73, Guillaume F4HDK
Le 24/03/2019 à 19:14, David Ranch a écrit :
Very cool Guillaume and thank you for posting! I'll have to dig into site more and send you some more questions.
Question 1: are you planning on offering any hardware kits or complete build of this hardware?
Question 2: do you think it's possible to lower the data rate to the point that omni-directional antennas would work decently well?
--David KI6ZHD
On 03/24/2019 01:05 AM, f4hdk wrote:
Hello,
I am Guillaume, callsign F4HDK, a french amateur-radio operator, and a hacker-maker. I would like to share with you my last project : NPR (New Packet Radio).
All documentation is provided here : https://hackaday.io/project/164092-npr-new-packet-radio
This solution can transport bi directional IP trafic over 70cm radio links, in a 'point to multipoint' topology, at datarate up to 500kbps. This can be used to increase the range of existing HSMM-Hamnet networks, at lower datarates. It's designed for "access", not backbone, and not designed for H24 use. Its is 100% open-source.
Do not hesitate to ask me questions about it. I hope it will interest some people here.
Guillaume:
A few questions is I may:
Answer 2 : In order to achieve links with omnidirectional antennas, you have to lower the datarate drastically. In order to do so, I would need to change lots and lots of things in my protocol, which is not designed for such low datarates. Therefore, I will not make such a development, sorry.
Why does the choice of antenna pattern affect the data rate?
Also, have you performed any testing to understand data rate vs. SINAD or SNR? If so, can you show what SINAD or SNR is needed to achieve each of the modulations (13, 14, 22, 23, 24)?
It appears that the modulation (13, 14, 22, 23, 24) is set statically in the master and applies to all remotes. Is this correct, or will the master dynamically change modulation for each client, depending on SNR?
Thanks much, Michael, N6MEF
Although my understanding of such things far from complete, I have heard that one of the biggest problems with high data rate radio is "smearing" of the symbols by multipath, and that if you can achieve little or no multipath (akin to analog TV "ghosting"), you can use much less robust modulation schemes to achieve higher symbol rates.
No doubt Guillaume can correct me on this. - Brian
On Sun, Mar 24, 2019 at 06:27:04PM -0700, Michael Fox - N6MEF wrote:
Guillaume:
A few questions is I may:
Answer 2 : In order to achieve links with omnidirectional antennas, you have to lower the datarate drastically. In order to do so, I would need to change lots and lots of things in my protocol, which is not designed for such low datarates. Therefore, I will not make such a development, sorry.
Why does the choice of antenna pattern affect the data rate?
Also, have you performed any testing to understand data rate vs. SINAD or SNR? If so, can you show what SINAD or SNR is needed to achieve each of the modulations (13, 14, 22, 23, 24)?
It appears that the modulation (13, 14, 22, 23, 24) is set statically in the master and applies to all remotes. Is this correct, or will the master dynamically change modulation for each client, depending on SNR?
Thanks much, Michael, N6MEF
Although my understanding of such things far from complete, I have heard that one of the biggest problems with high data rate radio is "smearing" of the symbols by multipath, and that if you can achieve little or no multipath (akin to analog TV "ghosting"), you can use much less robust modulation schemes to achieve higher symbol rates.
No doubt Guillaume can correct me on this.
- Brian
Brian,
Yes, I understand that. But he shows an omni at the central site. And a directional antenna doesn't eliminate multi-path (although it can help reduce it, depending on the source of the multi-path). So, I didn't want to assume what he meant by " In order to achieve links with omnidirectional antennas, you have to lower the datarate drastically".
Michael
Hello Brian, Hello Michael,
Brian is right about multipath.
But with an unobstructed omnidirectional antenna for the NPR Master (the central repeater), and diretional antennas (Yagi) at clients-user side (even partially obstructed), you avoid almost totally the multipath problem, and you can increase the symbol rate. That is exactly what we do here in the suburb of Paris with my protocol NPR (New Packet Radio) at 500kS/s. This is also well explained here by the Slovenian team. http://lea.hamradio.si/~s53mv/nbp/link.html
Furtheremore, here in France, the radioamateur rules request us to use horizontal polarisation for “high bandwidth” protocols, on the 70cm band.
If you want to make data links with only omnidirectional antennas, then you should * either use lower symbol rates (<200 kS/s) * or use more complex modulations, like COFDM
Last, but not least, in order to achieve good distance links, you need much better radio links with such wide band protocol, than with a narrow band protocol. Therefore, you need gain antenna, and Yagi is an easy solution.
73, Guillaume F4HDK
Le 25/03/2019 à 08:30, Michael Fox - N6MEF a écrit :
Although my understanding of such things far from complete, I have heard that one of the biggest problems with high data rate radio is "smearing" of the symbols by multipath, and that if you can achieve little or no multipath (akin to analog TV "ghosting"), you can use much less robust modulation schemes to achieve higher symbol rates.
No doubt Guillaume can correct me on this.
- Brian
Brian,
Yes, I understand that. But he shows an omni at the central site. And a directional antenna doesn't eliminate multi-path (although it can help reduce it, depending on the source of the multi-path). So, I didn't want to assume what he meant by " In order to achieve links with omnidirectional antennas, you have to lower the datarate drastically".
Michael
Michael,
1) I will try to make some measurement about minimum SNR, for each modulation, and add that to the documentation. 2) Yes, the modulation is set once for the Master and therefore is imposed to all NPR-clients. If the client is not configured with the right modulation parameter, it cannot talk to the Master. With the radio modules that I use, based on SI4463, you cannot change this setting "on the fly".
73, Guillaume F4HDK
Le 25/03/2019 à 02:27, Michael Fox - N6MEF a écrit :
Guillaume:
A few questions is I may:
Answer 2 : In order to achieve links with omnidirectional antennas, you have to lower the datarate drastically. In order to do so, I would need to change lots and lots of things in my protocol, which is not designed for such low datarates. Therefore, I will not make such a development, sorry.
Why does the choice of antenna pattern affect the data rate?
Also, have you performed any testing to understand data rate vs. SINAD or SNR? If so, can you show what SINAD or SNR is needed to achieve each of the modulations (13, 14, 22, 23, 24)?
It appears that the modulation (13, 14, 22, 23, 24) is set statically in the master and applies to all remotes. Is this correct, or will the master dynamically change modulation for each client, depending on SNR?
Thanks much, Michael, N6MEF
OK. Thanks!MichaelSent from my Verizon, Samsung Galaxy smartphone -------- Original message --------From: f4hdk f4hdk@free.fr Date: 3/25/19 12:50 (GMT-08:00) To: 44net@mailman.ampr.org Subject: Re: [44net] Hamnet over 70cm : NPR (New Packet Radio) Michael,1) I will try to make some measurement about minimum SNR, for each modulation, and add that to the documentation.2) Yes, the modulation is set once for the Master and therefore is imposed to all NPR-clients. If the client is not configured with the right modulation parameter, it cannot talk to the Master. With the radio modules that I use, based on SI4463, you cannot change this setting "on the fly".73,Guillaume F4HDKLe 25/03/2019 à 02:27, Michael Fox - N6MEF a écrit :> Guillaume:>> A few questions is I may:>>> Answer 2 : In order to achieve links with omnidirectional antennas, you>> have to lower the datarate drastically. In order to do so, I would need>> to change lots and lots of things in my protocol, which is not designed>> for such low datarates. Therefore, I will not make such a development,>> sorry.> Why does the choice of antenna pattern affect the data rate?>> Also, have you performed any testing to understand data rate vs. SINAD or> SNR? If so, can you show what SINAD or SNR is needed to achieve each of the> modulations (13, 14, 22, 23, 24)?>> It appears that the modulation (13, 14, 22, 23, 24) is set statically in the> master and applies to all remotes. Is this correct, or will the master> dynamically change modulation for each client, depending on SNR?>> Thanks much,> Michael, N6MEF>>>_________________________________________44Net mailing list44Net@mailman.ampr.orghttps://mailman.ampr.org/mailman/listinfo/44net
People, would you PLEASE not send undifferentiated piles of text like that below to the mailing list. It is discourteous to your audience.
Unfortunately, I can't figure out any way to filter these out and reject the posting other than to moderate every submission to the list, which is not practical to do.
Please demonstrate that proper formatting and editing of email discussions is not a lost art!
Thank you. - Brian
On Mon, Mar 25, 2019 at 03:57:52PM -0700, Michael Fox wrote:
OK. Thanks!MichaelSent from my Verizon, Samsung Galaxy smartphone -------- Original message --------From: f4hdk f4hdk@free.fr Date: 3/25/19 12:50 (GMT-08:00) To: 44net@mailman.ampr.org Subject: Re: [44net] Hamnet over 70cm : NPR (New Packet Radio) Michael,1) I will try to make some measurement about minimum SNR, for each modulation, and add that to the documentation.2) Yes, the modulation is set once for the Master and therefore is imposed to all NPR-clients. If the client is not configured with the right modulation parameter, it cannot talk to the Master. With the radio modules that I use, based on SI4463, you cannot change this setting "on the fly".73,Guillaume F4HDKLe 25/03/2019 à 02:27, Michael Fox - N6MEF a écrit :> Guillaume:>> A few questions is I may:>>> Answer 2 : In order to achieve links with omnidirectional antennas, you>> have to lower the datarate drastically. In order to do so, I would need>> to change lots and lots of things in my protocol, which is not designed>> for such low datarates. Therefore, I will not make such a development,>> sorry.> Why does the choice of antenna pattern affect the data rate?>> Also, have you performed any testing to understand data rate vs. SINAD or> SNR? If so, can you show what SINAD or SNR is needed to achieve each of the> modulations (13, 14, 22, 23, 24)?>> It appears that the modulation (13, 14, 22, 23, 24) is set statically in the> master and applies to all remotes. Is this correct, or will the master> dynamically change modulation for each client, depending on SNR?>> Thanks much,> Michael, N6MEF>>>_________________________________________44Net mailing list44Net@mailman.ampr.orghttps://mailman.ampr.org/mailman/listinfo/44net
I want this!!!!!!
I note that you have used a Dorji radio module modules which have variable rise times in the order of over half a second. How did you overcome this?
Got a link to the project?
Mark
On Sun, Mar 24, 2019 at 4:05 AM f4hdk f4hdk@free.fr wrote:
Hello,
I am Guillaume, callsign F4HDK, a french amateur-radio operator, and a hacker-maker. I would like to share with you my last project : NPR (New Packet Radio).
All documentation is provided here : https://hackaday.io/project/164092-npr-new-packet-radio
This solution can transport bi directional IP trafic over 70cm radio links, in a 'point to multipoint' topology, at datarate up to 500kbps. This can be used to increase the range of existing HSMM-Hamnet networks, at lower datarates. It's designed for "access", not backbone, and not designed for H24 use. Its is 100% open-source.
Do not hesitate to ask me questions about it. I hope it will interest some people here.
73, Guillaume F4HDK _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
I note that at the advertised bit rates, the OBW (occupied bandwidth) may exceed US Regulations for 70cm. However, the chip used, is also claimed to support 33cm.
I am interested in the new packet protocol proposed by the project. Even at a lower bps on 70cm (for the US), and full rate at 33cm, this has real potential for mid-tier data communications.
CFR 47 Part 97.307 (f) 6
On Sun, Mar 24, 2019 at 4:05 AM f4hdk f4hdk@free.fr wrote:
Hello,
I am Guillaume, callsign F4HDK, a french amateur-radio operator, and a hacker-maker. I would like to share with you my last project : NPR (New Packet Radio).
All documentation is provided here : https://hackaday.io/project/164092-npr-new-packet-radio
This solution can transport bi directional IP trafic over 70cm radio links, in a 'point to multipoint' topology, at datarate up to 500kbps. This can be used to increase the range of existing HSMM-Hamnet networks, at lower datarates. It's designed for "access", not backbone, and not designed for H24 use. Its is 100% open-source.
Do not hesitate to ask me questions about it. I hope it will interest some people here.
73, Guillaume F4HDK
------------------------------ John D. Hays K7VE http://k7ve.org/blog http://twitter.com/#!/john_hays http://www.facebook.com/john.d.hays
We keep hitting this bandwidth wall. I say we should just ignore it. We are never gonna get a change if we don't show the need for it.
On Sun, Mar 24, 2019 at 2:36 PM K7VE - John k7ve@k7ve.org wrote:
I note that at the advertised bit rates, the OBW (occupied bandwidth) may exceed US Regulations for 70cm. However, the chip used, is also claimed to support 33cm.
I am interested in the new packet protocol proposed by the project. Even at a lower bps on 70cm (for the US), and full rate at 33cm, this has real potential for mid-tier data communications.
CFR 47 Part 97.307 (f) 6
On Sun, Mar 24, 2019 at 4:05 AM f4hdk f4hdk@free.fr wrote:
Hello,
I am Guillaume, callsign F4HDK, a french amateur-radio operator, and a hacker-maker. I would like to share with you my last project : NPR (New Packet
Radio).
All documentation is provided here : https://hackaday.io/project/164092-npr-new-packet-radio
This solution can transport bi directional IP trafic over 70cm radio links, in a 'point to multipoint' topology, at datarate up to 500kbps. This can be used to increase the range of existing HSMM-Hamnet
networks,
at lower datarates. It's designed for "access", not backbone, and not designed for H24 use. Its is 100% open-source.
Do not hesitate to ask me questions about it. I hope it will interest some people here.
73, Guillaume F4HDK
John D. Hays K7VE http://k7ve.org/blog http://twitter.com/#!/john_hays http://www.facebook.com/john.d.hays _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
I had another thought about the bandwidth.
Why can digital ATV get away with it and we cannot? Their data rates get up to mbps. They justify it by calling it "TV" rather than data.
On Sun, Mar 24, 2019 at 2:52 PM Mark Phillips g7ltt@g7ltt.com wrote:
We keep hitting this bandwidth wall. I say we should just ignore it. We are never gonna get a change if we don't show the need for it.
On Sun, Mar 24, 2019 at 2:36 PM K7VE - John k7ve@k7ve.org wrote:
I note that at the advertised bit rates, the OBW (occupied bandwidth) may exceed US Regulations for 70cm. However, the chip used, is also claimed to support 33cm.
I am interested in the new packet protocol proposed by the project. Even at a lower bps on 70cm (for the US), and full rate at 33cm, this has real potential for mid-tier data communications.
CFR 47 Part 97.307 (f) 6
On Sun, Mar 24, 2019 at 4:05 AM f4hdk f4hdk@free.fr wrote:
Hello,
I am Guillaume, callsign F4HDK, a french amateur-radio operator, and a hacker-maker. I would like to share with you my last project : NPR (New Packet
Radio).
All documentation is provided here : https://hackaday.io/project/164092-npr-new-packet-radio
This solution can transport bi directional IP trafic over 70cm radio links, in a 'point to multipoint' topology, at datarate up to 500kbps. This can be used to increase the range of existing HSMM-Hamnet
networks,
at lower datarates. It's designed for "access", not backbone, and not designed for H24
use.
Its is 100% open-source.
Do not hesitate to ask me questions about it. I hope it will interest some people here.
73, Guillaume F4HDK
John D. Hays K7VE http://k7ve.org/blog http://twitter.com/#!/john_hays http://www.facebook.com/john.d.hays _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
This keeps coming up. Has anyone ever submitted a petition for rule making to the FCC? Or are folks afraid that stirring the pot will get DATV banned on 70 cm?
Ron W6RZ
On 3/24/19 12:09, Mark Phillips wrote:
I had another thought about the bandwidth.
Why can digital ATV get away with it and we cannot? Their data rates get up to mbps. They justify it by calling it "TV" rather than data.
On Sun, Mar 24, 2019 at 2:52 PM Mark Phillips g7ltt@g7ltt.com wrote:
We keep hitting this bandwidth wall. I say we should just ignore it. We are never gonna get a change if we don't show the need for it.
On Sun, Mar 24, 2019 at 2:36 PM K7VE - John k7ve@k7ve.org wrote:
I note that at the advertised bit rates, the OBW (occupied bandwidth) may exceed US Regulations for 70cm. However, the chip used, is also claimed to support 33cm.
I am interested in the new packet protocol proposed by the project. Even at a lower bps on 70cm (for the US), and full rate at 33cm, this has real potential for mid-tier data communications.
CFR 47 Part 97.307 (f) 6
Ron, Every chance I get to make FCC comment I mention this. That is just a comment though, not an actual petition. Either way it takes patience and a long life to get anywhere with getting regulations changed.
Since this uses TDMA modulation I'd say it could be classified as spread spectrum? Either way if this thing becomes an option in the US to buy or build as a kit, rest assured whatever archaic regulations still exist will be ignored by myself.
Since you asked: The ARRL has sort of (half-assed/not well thought*) tried to address this half-ass symbol rate business. Their efforts date back to September 2013. The Dec 23 2013 comment deadline, yielded more than 850 comments had been filed, which was a large number indicating that the issue of data communications is an important one in the Amateur Radio Service.
From the conclusion of the rule making proposal (7/28/16):
In summary, we believe that the public interest may be served by revising the amateur service rules to eliminate the current baud rate limitations for data emissions consistent with ARRL’s Petition to allow amateur service licensees to use modern digital emissions, thereby furthering the purposes of the amateur service and enhancing the usefulness of the service. We do not, however, propose a bandwidth limitation for data emissions in the MF and HF bands to replace the baud rate limitations, because the rules’ current approach for limiting bandwidth use by amateur stations using one of the specified digital codes to encode the signal being transmitted appears sufficient to ensure that general access to the band by licensees in the amateur service does not become unduly impaired.
In short:. They agree that a hard baud limit is not good, but the bandwidth limit proposed by ARRL isn't any better, so FCC denied the request. And I haven't see the league make any subsequent revised proposals or petitions.
*The proposal to modernize the rules for data transmissions called for the baud rate limits to be removed, and will governed by just the maximum bandwidth portion of the existing rules. The present rule for the 70 centimeter band is 56 kilobauds/100 kHz. If the FCC would have approved the request we'd have just a 100 kHz wide limit. With present technology, using 4FSK or QPSK Modulation is should be possible to achieve near 170kbps in that 100 kHz. The petition does fall short of addressing bandwidth for image (6 MHz) verses data emissions (100 kHz), which is very disappointing.
On Sun, Mar 24, 2019 at 3:13 PM Ron Economos via 44Net 44net@mailman.ampr.org wrote:
This keeps coming up. Has anyone ever submitted a petition for rule making to the FCC? Or are folks afraid that stirring the pot will get DATV banned on 70 cm?
Ron W6RZ
On 3/24/19 12:09, Mark Phillips wrote:
I had another thought about the bandwidth.
Why can digital ATV get away with it and we cannot? Their data rates get up to mbps. They justify it by calling it "TV" rather than data.
On Sun, Mar 24, 2019 at 2:52 PM Mark Phillips g7ltt@g7ltt.com wrote:
We keep hitting this bandwidth wall. I say we should just ignore it. We are never gonna get a change if we don't show the need for it.
On Sun, Mar 24, 2019 at 2:36 PM K7VE - John k7ve@k7ve.org wrote:
I note that at the advertised bit rates, the OBW (occupied bandwidth) may exceed US Regulations for 70cm. However, the chip used, is also claimed to support 33cm.
I am interested in the new packet protocol proposed by the project. Even at a lower bps on 70cm (for the US), and full rate at 33cm, this has real potential for mid-tier data communications.
CFR 47 Part 97.307 (f) 6
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Yeah, the symbol rate petition got all conflated with Winlink and HF e-mail. Any time there are many comments on a petition with about 50/50 for/against, the FCC punts.
I'm wondering if a very specific petition could work. Just change one line in 97.305(c).
Change:
70 cm Entire band MCW, phone, image, RTTY, data, SS, test (6), (8)
To:
70 cm Entire band MCW, phone, image, RTTY, data, SS, test (7), (8)
Essentially make 70 cm equal to 33 cm and above (except for F8E, which is fine).
Ron W6RZ
On 3/24/19 14:45, Steve L via 44Net wrote:
Ron, Every chance I get to make FCC comment I mention this. That is just a comment though, not an actual petition. Either way it takes patience and a long life to get anywhere with getting regulations changed.
Since this uses TDMA modulation I'd say it could be classified as spread spectrum? Either way if this thing becomes an option in the US to buy or build as a kit, rest assured whatever archaic regulations still exist will be ignored by myself.
Since you asked: The ARRL has sort of (half-assed/not well thought*) tried to address this half-ass symbol rate business. Their efforts date back to September 2013. The Dec 23 2013 comment deadline, yielded more than 850 comments had been filed, which was a large number indicating that the issue of data communications is an important one in the Amateur Radio Service.
From the conclusion of the rule making proposal (7/28/16):
In summary, we believe that the public interest may be served by revising the amateur service rules to eliminate the current baud rate limitations for data emissions consistent with ARRL’s Petition to allow amateur service licensees to use modern digital emissions, thereby furthering the purposes of the amateur service and enhancing the usefulness of the service. We do not, however, propose a bandwidth limitation for data emissions in the MF and HF bands to replace the baud rate limitations, because the rules’ current approach for limiting bandwidth use by amateur stations using one of the specified digital codes to encode the signal being transmitted appears sufficient to ensure that general access to the band by licensees in the amateur service does not become unduly impaired.
In short:. They agree that a hard baud limit is not good, but the bandwidth limit proposed by ARRL isn't any better, so FCC denied the request. And I haven't see the league make any subsequent revised proposals or petitions.
*The proposal to modernize the rules for data transmissions called for the baud rate limits to be removed, and will governed by just the maximum bandwidth portion of the existing rules. The present rule for the 70 centimeter band is 56 kilobauds/100 kHz. If the FCC would have approved the request we'd have just a 100 kHz wide limit. With present technology, using 4FSK or QPSK Modulation is should be possible to achieve near 170kbps in that 100 kHz. The petition does fall short of addressing bandwidth for image (6 MHz) verses data emissions (100 kHz), which is very disappointing.
On Sun, Mar 24, 2019 at 3:13 PM Ron Economos via 44Net 44net@mailman.ampr.org wrote:
This keeps coming up. Has anyone ever submitted a petition for rule making to the FCC? Or are folks afraid that stirring the pot will get DATV banned on 70 cm?
Ron W6RZ
On 3/24/19 12:09, Mark Phillips wrote:
I had another thought about the bandwidth.
Why can digital ATV get away with it and we cannot? Their data rates get up to mbps. They justify it by calling it "TV" rather than data.
On Sun, Mar 24, 2019 at 2:52 PM Mark Phillips g7ltt@g7ltt.com wrote:
We keep hitting this bandwidth wall. I say we should just ignore it. We are never gonna get a change if we don't show the need for it.
On Sun, Mar 24, 2019 at 2:36 PM K7VE - John k7ve@k7ve.org wrote:
I note that at the advertised bit rates, the OBW (occupied bandwidth) may exceed US Regulations for 70cm. However, the chip used, is also claimed to support 33cm.
I am interested in the new packet protocol proposed by the project. Even at a lower bps on 70cm (for the US), and full rate at 33cm, this has real potential for mid-tier data communications.
CFR 47 Part 97.307 (f) 6
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
In case anyone feels the need:
It's pretty easy to file a petition through the ECFS. When you go to the main ECFS page https://www.fcc.gov/ecfs/filings in "Type of filing" select "petition for rule making", and fill out the rest of the form and upload your petition.
A couple useful pages from the FCC: https://www.publicknowledge.org/assets/uploads/blog/RP_FCCPetitiontoDeny.pdf https://www.fcc.gov/about-fcc/rulemaking-process Here is a quick summary from the last one, three are more details on the page. *Organized comments*. *Clear explanation and support for views*. *Alternatives. * *Examples of concerns.* *Statutory limitations.*
It's also helpful to review recent amateur petitions and the FCC response. The rejections are a wealth of information on what not to do. It might be advisable to suggest RM-11392 and DA 08-1092 rejection, RM-11699 and DA 13-1918 rejection, as starting points since its somewhat related.
Don't use ham jargon, be sure sure to explain acronyms at least once in the filing, if repeated makes it easier to follow. Don't bash other amateur modes or practices. Don't use technical terms unless fully explained so a lawyer can understand, most on the Commission are non-tech types. Don't ask to ban anything, if you want that done make the case to the FCC that whatever it is is poor practice without requesting a ban......let them do it.
Do make your petition concise and to the point without a lot of rambling and legalese. Do provide a reason as to why it's a benefit to the amateur service as a whole, also in the public interest if it applies. Do have someone, with the background to understand it, proofread and comment. Do be ready for rebuttal of comments if there are any opposing....wait for the "reply to comment" period, this isn't an internet forum squabble. Keep comments/reply to civil and professional.
On Sun, Mar 24, 2019 at 3:13 PM Ron Economos via 44Net 44net@mailman.ampr.org wrote:
This keeps coming up. Has anyone ever submitted a petition for rule making to the FCC? Or are folks afraid that stirring the pot will get DATV banned on 70 cm?
Ron W6RZ
Got a pair of these modems working! They are just running across the bench right now. I have an RPi3 and a MMDVM hotspot connected to the client (via a switch) with the master connected to a spare port on the back of my pfSense firewall. I'm using mode "22" which is 270KHz wide for about 220kbps of data bandwidth. This seems more than able to handle the serving of a web age and running the MMDVM. I also did a test in 500kbps mode using a wifi hotspot attached to the client. I was able to sustain a "wifi calling" cellphone conversation for over an hour with no issues.
For those not following the project, new firmware was released this weekend that allows tuning of the RF from 420-450MHz which is a great improvement over the EU only bandplan.
Take a look here http://g7ltt.dyndns.org:2210
Mark G7LTT/NI2O
On Tue, Mar 26, 2019 at 4:24 PM Steve L via 44Net 44net@mailman.ampr.org wrote:
In case anyone feels the need:
It's pretty easy to file a petition through the ECFS. When you go to the main ECFS page https://www.fcc.gov/ecfs/filings in "Type of filing" select "petition for rule making", and fill out the rest of the form and upload your petition.
A couple useful pages from the FCC: < https://www.publicknowledge.org/assets/uploads/blog/RP_FCCPetitiontoDeny.pdf
https://www.fcc.gov/about-fcc/rulemaking-process Here is a quick summary from the last one, three are more details on the page. *Organized comments*. *Clear explanation and support for views*. *Alternatives. * *Examples of concerns.* *Statutory limitations.*
It's also helpful to review recent amateur petitions and the FCC response. The rejections are a wealth of information on what not to do. It might be advisable to suggest RM-11392 and DA 08-1092 rejection, RM-11699 and DA 13-1918 rejection, as starting points since its somewhat related.
Don't use ham jargon, be sure sure to explain acronyms at least once in the filing, if repeated makes it easier to follow. Don't bash other amateur modes or practices. Don't use technical terms unless fully explained so a lawyer can understand, most on the Commission are non-tech types. Don't ask to ban anything, if you want that done make the case to the FCC that whatever it is is poor practice without requesting a ban......let them do it.
Do make your petition concise and to the point without a lot of rambling and legalese. Do provide a reason as to why it's a benefit to the amateur service as a whole, also in the public interest if it applies. Do have someone, with the background to understand it, proofread and comment. Do be ready for rebuttal of comments if there are any opposing....wait for the "reply to comment" period, this isn't an internet forum squabble. Keep comments/reply to civil and professional.
On Sun, Mar 24, 2019 at 3:13 PM Ron Economos via 44Net 44net@mailman.ampr.org wrote:
This keeps coming up. Has anyone ever submitted a petition for rule making to the FCC? Or are folks afraid that stirring the pot will get DATV banned on 70 cm?
Ron W6RZ
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Great to hear and thanks for the update Mark. Has there been any mention of supporting smaller bandwidths in the future?
--David KI6ZHD
On 06/02/2019 05:27 PM, Mark Phillips wrote:
Got a pair of these modems working! They are just running across the bench right now. I have an RPi3 and a MMDVM hotspot connected to the client (via a switch) with the master connected to a spare port on the back of my pfSense firewall. I'm using mode "22" which is 270KHz wide for about 220kbps of data bandwidth. This seems more than able to handle the serving of a web age and running the MMDVM. I also did a test in 500kbps mode using a wifi hotspot attached to the client. I was able to sustain a "wifi calling" cellphone conversation for over an hour with no issues.
For those not following the project, new firmware was released this weekend that allows tuning of the RF from 420-450MHz which is a great improvement over the EU only bandplan.
Take a look here http://g7ltt.dyndns.org:2210
Mark G7LTT/NI2O
On Tue, Mar 26, 2019 at 4:24 PM Steve L via 44Net 44net@mailman.ampr.org wrote:
In case anyone feels the need:
It's pretty easy to file a petition through the ECFS. When you go to the main ECFS page https://www.fcc.gov/ecfs/filings in "Type of filing" select "petition for rule making", and fill out the rest of the form and upload your petition.
A couple useful pages from the FCC: < https://www.publicknowledge.org/assets/uploads/blog/RP_FCCPetitiontoDeny.pdf https://www.fcc.gov/about-fcc/rulemaking-process Here is a quick summary from the last one, three are more details on the page. *Organized comments*. *Clear explanation and support for views*. *Alternatives. * *Examples of concerns.* *Statutory limitations.*
It's also helpful to review recent amateur petitions and the FCC response. The rejections are a wealth of information on what not to do. It might be advisable to suggest RM-11392 and DA 08-1092 rejection, RM-11699 and DA 13-1918 rejection, as starting points since its somewhat related.
Don't use ham jargon, be sure sure to explain acronyms at least once in the filing, if repeated makes it easier to follow. Don't bash other amateur modes or practices. Don't use technical terms unless fully explained so a lawyer can understand, most on the Commission are non-tech types. Don't ask to ban anything, if you want that done make the case to the FCC that whatever it is is poor practice without requesting a ban......let them do it.
Do make your petition concise and to the point without a lot of rambling and legalese. Do provide a reason as to why it's a benefit to the amateur service as a whole, also in the public interest if it applies. Do have someone, with the background to understand it, proofread and comment. Do be ready for rebuttal of comments if there are any opposing....wait for the "reply to comment" period, this isn't an internet forum squabble. Keep comments/reply to civil and professional.
On Sun, Mar 24, 2019 at 3:13 PM Ron Economos via 44Net 44net@mailman.ampr.org wrote:
This keeps coming up. Has anyone ever submitted a petition for rule making to the FCC? Or are folks afraid that stirring the pot will get DATV banned on 70 cm?
Ron W6RZ
David et al,
No mention yet. But in the usual #metoo way a few other projects have crawled out of the woodwork. Take a look at this https://destevez.net/2016/06/using-the-cc1101-and-beaglebone-black-for-ip-tr... for `128kbps in 100KHz and a similar one here http://wiki.oevsv.at/index.php/Kategorie:HHD70
Mark
On Sun, Jun 2, 2019 at 10:00 PM David Ranch amprgw@trinnet.net wrote:
Great to hear and thanks for the update Mark. Has there been any mention of supporting smaller bandwidths in the future?
--David KI6ZHD
On 06/02/2019 05:27 PM, Mark Phillips wrote:
Got a pair of these modems working! They are just running across the
bench
right now. I have an RPi3 and a MMDVM hotspot connected to the client
(via
a switch) with the master connected to a spare port on the back of my pfSense firewall. I'm using mode "22" which is 270KHz wide for about 220kbps of data bandwidth. This seems more than able to handle the
serving
of a web age and running the MMDVM. I also did a test in 500kbps mode
using
a wifi hotspot attached to the client. I was able to sustain a "wifi calling" cellphone conversation for over an hour with no issues.
For those not following the project, new firmware was released this
weekend
that allows tuning of the RF from 420-450MHz which is a great improvement over the EU only bandplan.
Take a look here http://g7ltt.dyndns.org:2210
Mark G7LTT/NI2O
On Tue, Mar 26, 2019 at 4:24 PM Steve L via 44Net <
44net@mailman.ampr.org>
wrote:
In case anyone feels the need:
It's pretty easy to file a petition through the ECFS. When you go to the main ECFS page https://www.fcc.gov/ecfs/filings in "Type of filing" select "petition for rule making", and fill out the rest of the form and upload your petition.
A couple useful pages from the FCC: <
https://www.publicknowledge.org/assets/uploads/blog/RP_FCCPetitiontoDeny.pdf
https://www.fcc.gov/about-fcc/rulemaking-process Here is a quick summary from the last one, three are more details on the page. *Organized comments*. *Clear explanation and support for views*. *Alternatives. * *Examples of concerns.* *Statutory limitations.*
It's also helpful to review recent amateur petitions and the FCC response. The rejections are a wealth of information on what not to do. It might be advisable to suggest RM-11392 and DA 08-1092 rejection, RM-11699 and DA 13-1918 rejection, as starting points since its somewhat related.
Don't use ham jargon, be sure sure to explain acronyms at least once in the filing, if repeated makes it easier to follow. Don't bash other amateur modes or practices. Don't use technical terms unless fully explained so a lawyer can understand, most on the Commission are non-tech types. Don't ask to ban anything, if you want that done make the case to the FCC that whatever it is is poor practice without requesting a ban......let them do it.
Do make your petition concise and to the point without a lot of rambling and legalese. Do provide a reason as to why it's a benefit to the amateur service as a whole, also in the public interest if it applies. Do have someone, with the background to understand it, proofread and comment. Do be ready for rebuttal of comments if there are any opposing....wait for the "reply to comment" period, this isn't an internet forum squabble. Keep comments/reply to civil and professional.
On Sun, Mar 24, 2019 at 3:13 PM Ron Economos via 44Net 44net@mailman.ampr.org wrote:
This keeps coming up. Has anyone ever submitted a petition for rule making to the FCC? Or are folks afraid that stirring the pot will get DATV banned on 70 cm?
Ron W6RZ
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Hello,
Yes, I will try to provide smaller bandwidths in the following months (or weeks?) for NPR. Probably ~180kHz, which could carry ~90kbps with 2GFSK and ~160kbps with 4GFSK (net datarate).
But I don't think that I will propose modulation parameters which could match the (very small) FCC restrictions (100kHz and 56kbaud if I remember well). This rule seems outdated to me... even if it still applies.
Do not hesitate to take a look regularly at my hackaday web-page in order to keep informed about "New Packet Radio". https://hackaday.io/project/164092-npr-new-packet-radio
73, Guillaume F4HDK
Le 03/06/2019 à 04:00, David Ranch a écrit :
Great to hear and thanks for the update Mark. Has there been any mention of supporting smaller bandwidths in the future?
--David KI6ZHD
On 06/02/2019 05:27 PM, Mark Phillips wrote:
Got a pair of these modems working! They are just running across the bench right now. I have an RPi3 and a MMDVM hotspot connected to the client (via a switch) with the master connected to a spare port on the back of my pfSense firewall. I'm using mode "22" which is 270KHz wide for about 220kbps of data bandwidth. This seems more than able to handle the serving of a web age and running the MMDVM. I also did a test in 500kbps mode using a wifi hotspot attached to the client. I was able to sustain a "wifi calling" cellphone conversation for over an hour with no issues.
For those not following the project, new firmware was released this weekend that allows tuning of the RF from 420-450MHz which is a great improvement over the EU only bandplan.
Take a look here http://g7ltt.dyndns.org:2210
Mark G7LTT/NI2O
On Tue, Mar 26, 2019 at 4:24 PM Steve L via 44Net 44net@mailman.ampr.org wrote:
In case anyone feels the need:
It's pretty easy to file a petition through the ECFS. When you go to the main ECFS page https://www.fcc.gov/ecfs/filings in "Type of filing" select "petition for rule making", and fill out the rest of the form and upload your petition.
A couple useful pages from the FCC: < https://www.publicknowledge.org/assets/uploads/blog/RP_FCCPetitiontoDeny.pdf
https://www.fcc.gov/about-fcc/rulemaking-process Here is a quick summary from the last one, three are more details on the page. *Organized comments*. *Clear explanation and support for views*. *Alternatives. * *Examples of concerns.* *Statutory limitations.*
It's also helpful to review recent amateur petitions and the FCC response. The rejections are a wealth of information on what not to do. It might be advisable to suggest RM-11392 and DA 08-1092 rejection, RM-11699 and DA 13-1918 rejection, as starting points since its somewhat related.
Don't use ham jargon, be sure sure to explain acronyms at least once in the filing, if repeated makes it easier to follow. Don't bash other amateur modes or practices. Don't use technical terms unless fully explained so a lawyer can understand, most on the Commission are non-tech types. Don't ask to ban anything, if you want that done make the case to the FCC that whatever it is is poor practice without requesting a ban......let them do it.
Do make your petition concise and to the point without a lot of rambling and legalese. Do provide a reason as to why it's a benefit to the amateur service as a whole, also in the public interest if it applies. Do have someone, with the background to understand it, proofread and comment. Do be ready for rebuttal of comments if there are any opposing....wait for the "reply to comment" period, this isn't an internet forum squabble. Keep comments/reply to civil and professional.
On Sun, Mar 24, 2019 at 3:13 PM Ron Economos via 44Net 44net@mailman.ampr.org wrote:
This keeps coming up. Has anyone ever submitted a petition for rule making to the FCC? Or are folks afraid that stirring the pot will get DATV banned on 70 cm?
Ron W6RZ
Yes, the 100KHz rule is still alive and well here in the US. I agree it's old but its there so we should at least try to abide by it.
Even 56K would be a significant improvement on the 1k2 and 9k6 we have currently.
Keep up the good work!!
Mark
On Mon, Jun 3, 2019 at 4:16 PM f4hdk f4hdk@free.fr wrote:
Hello,
Yes, I will try to provide smaller bandwidths in the following months (or weeks?) for NPR. Probably ~180kHz, which could carry ~90kbps with 2GFSK and ~160kbps with 4GFSK (net datarate).
But I don't think that I will propose modulation parameters which could match the (very small) FCC restrictions (100kHz and 56kbaud if I remember well). This rule seems outdated to me... even if it still applies.
Do not hesitate to take a look regularly at my hackaday web-page in order to keep informed about "New Packet Radio". https://hackaday.io/project/164092-npr-new-packet-radio
73, Guillaume F4HDK
Le 03/06/2019 à 04:00, David Ranch a écrit :
Great to hear and thanks for the update Mark. Has there been any mention of supporting smaller bandwidths in the future?
--David KI6ZHD
On 06/02/2019 05:27 PM, Mark Phillips wrote:
Got a pair of these modems working! They are just running across the bench right now. I have an RPi3 and a MMDVM hotspot connected to the client (via a switch) with the master connected to a spare port on the back of my pfSense firewall. I'm using mode "22" which is 270KHz wide for about 220kbps of data bandwidth. This seems more than able to handle the serving of a web age and running the MMDVM. I also did a test in 500kbps mode using a wifi hotspot attached to the client. I was able to sustain a "wifi calling" cellphone conversation for over an hour with no issues.
For those not following the project, new firmware was released this weekend that allows tuning of the RF from 420-450MHz which is a great improvement over the EU only bandplan.
Take a look here http://g7ltt.dyndns.org:2210
Mark G7LTT/NI2O
On Tue, Mar 26, 2019 at 4:24 PM Steve L via 44Net 44net@mailman.ampr.org wrote:
In case anyone feels the need:
It's pretty easy to file a petition through the ECFS. When you go to the main ECFS page https://www.fcc.gov/ecfs/filings in "Type of filing" select "petition for rule making", and fill out the rest of the form and upload your petition.
A couple useful pages from the FCC: <
https://www.publicknowledge.org/assets/uploads/blog/RP_FCCPetitiontoDeny.pdf
https://www.fcc.gov/about-fcc/rulemaking-process Here is a quick summary from the last one, three are more details on the page. *Organized comments*. *Clear explanation and support for views*. *Alternatives. * *Examples of concerns.* *Statutory limitations.*
It's also helpful to review recent amateur petitions and the FCC response. The rejections are a wealth of information on what not to do. It might be advisable to suggest RM-11392 and DA 08-1092 rejection, RM-11699 and DA 13-1918 rejection, as starting points since its somewhat related.
Don't use ham jargon, be sure sure to explain acronyms at least once in the filing, if repeated makes it easier to follow. Don't bash other amateur modes or practices. Don't use technical terms unless fully explained so a lawyer can understand, most on the Commission are non-tech types. Don't ask to ban anything, if you want that done make the case to the FCC that whatever it is is poor practice without requesting a ban......let them do it.
Do make your petition concise and to the point without a lot of rambling and legalese. Do provide a reason as to why it's a benefit to the amateur service as a whole, also in the public interest if it applies. Do have someone, with the background to understand it, proofread and comment. Do be ready for rebuttal of comments if there are any opposing....wait for the "reply to comment" period, this isn't an internet forum squabble. Keep comments/reply to civil and professional.
On Sun, Mar 24, 2019 at 3:13 PM Ron Economos via 44Net 44net@mailman.ampr.org wrote:
This keeps coming up. Has anyone ever submitted a petition for rule making to the FCC? Or are folks afraid that stirring the pot will get DATV banned on 70 cm?
Ron W6RZ
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Hello Guillaume,
Great to hear that you're willing to try narrower bandwidth offerings! That's a huge help to give this new mode you're working on a try. To your other point, unfortunately yes, the FCC restrictions here in the US are antiquated. Until they can be changed (the request is already been pending for YEARS), we have to live with them. Please not that it's the *symbol* rate that's limited for say 70cm. I would imagine that 70cm would be the most popular band to use in the US to experiment compared to say 33 cm or 23cm.
I had to look up the whole thing again but here is the exact FCC wording:
http://www.arrl.org/part-97-text *§97.305 Authorized emission types.*
--
UHF:
70 cm
Entire band
MCW, phone, image, RTTY, data, SS, test
(6), (8).
33 cm
Entire band
MCW, phone, image, RTTY, data, SS, test, pulse
(7), (8), and (12).
23 cm
Entire band
MCW, phone, image, RTTY, data, SS, test
(7), (8), and (12).
(f) The following standards and limitations apply to transmissions on the frequencies specified in §97.305(c) of this part.
(6) A RTTY, data or multiplexed emission using a specified digital code listed in §97.309(a) of this part may be transmitted. The symbol rate must not exceed 56 kilobauds. A RTTY, data or multiplexed emission using an unspecified digital code under the limitations listed in §97.309(b) of this part also may be transmitted. The authorized bandwidth is 100 kHz.
(7) A RTTY, data or multiplexed emission using a specified digital code listed in §97.309(a) of this part or an unspecified digital code under the limitations listed in §97.309(b) of this part may be transmitted.--
(8) A RTTY or data emission having designators with A, B, C, D, E, F, G, H, J or R as the first symbol; 1, 2, 7, 9 or X as the second symbol; and D or W as the third symbol is also authorized.
(12) Emission F8E may be transmitted. --
--David KI6ZHD
On 06/03/2019 01:16 PM, f4hdk wrote:
Hello,
Yes, I will try to provide smaller bandwidths in the following months (or weeks?) for NPR. Probably ~180kHz, which could carry ~90kbps with 2GFSK and ~160kbps with 4GFSK (net datarate).
But I don't think that I will propose modulation parameters which could match the (very small) FCC restrictions (100kHz and 56kbaud if I remember well). This rule seems outdated to me... even if it still applies.
Do not hesitate to take a look regularly at my hackaday web-page in order to keep informed about "New Packet Radio". https://hackaday.io/project/164092-npr-new-packet-radio
73, Guillaume F4HDK
Le 03/06/2019 à 04:00, David Ranch a écrit :
Great to hear and thanks for the update Mark. Has there been any mention of supporting smaller bandwidths in the future?
--David KI6ZHD
On 06/02/2019 05:27 PM, Mark Phillips wrote:
Got a pair of these modems working! They are just running across the bench right now. I have an RPi3 and a MMDVM hotspot connected to the client (via a switch) with the master connected to a spare port on the back of my pfSense firewall. I'm using mode "22" which is 270KHz wide for about 220kbps of data bandwidth. This seems more than able to handle the serving of a web age and running the MMDVM. I also did a test in 500kbps mode using a wifi hotspot attached to the client. I was able to sustain a "wifi calling" cellphone conversation for over an hour with no issues.
For those not following the project, new firmware was released this weekend that allows tuning of the RF from 420-450MHz which is a great improvement over the EU only bandplan.
Take a look here http://g7ltt.dyndns.org:2210
Mark G7LTT/NI2O
On Tue, Mar 26, 2019 at 4:24 PM Steve L via 44Net 44net@mailman.ampr.org wrote:
In case anyone feels the need:
It's pretty easy to file a petition through the ECFS. When you go to the main ECFS page https://www.fcc.gov/ecfs/filings in "Type of filing" select "petition for rule making", and fill out the rest of the form and upload your petition.
A couple useful pages from the FCC: < https://www.publicknowledge.org/assets/uploads/blog/RP_FCCPetitiontoDeny.pdf
https://www.fcc.gov/about-fcc/rulemaking-process Here is a quick summary from the last one, three are more details on the page. *Organized comments*. *Clear explanation and support for views*. *Alternatives. * *Examples of concerns.* *Statutory limitations.*
It's also helpful to review recent amateur petitions and the FCC response. The rejections are a wealth of information on what not to do. It might be advisable to suggest RM-11392 and DA 08-1092 rejection, RM-11699 and DA 13-1918 rejection, as starting points since its somewhat related.
Don't use ham jargon, be sure sure to explain acronyms at least once in the filing, if repeated makes it easier to follow. Don't bash other amateur modes or practices. Don't use technical terms unless fully explained so a lawyer can understand, most on the Commission are non-tech types. Don't ask to ban anything, if you want that done make the case to the FCC that whatever it is is poor practice without requesting a ban......let them do it.
Do make your petition concise and to the point without a lot of rambling and legalese. Do provide a reason as to why it's a benefit to the amateur service as a whole, also in the public interest if it applies. Do have someone, with the background to understand it, proofread and comment. Do be ready for rebuttal of comments if there are any opposing....wait for the "reply to comment" period, this isn't an internet forum squabble. Keep comments/reply to civil and professional.
On Sun, Mar 24, 2019 at 3:13 PM Ron Economos via 44Net 44net@mailman.ampr.org wrote:
This keeps coming up. Has anyone ever submitted a petition for rule making to the FCC? Or are folks afraid that stirring the pot will get DATV banned on 70 cm?
Ron W6RZ
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Here is something the late Stephenson, KD6OZH pointed out: Keep in mind that's 100 KHz per carrier. So if there was something OFDM with multiple carriers....
He also pointed out the image transmission thing as another way to point out how ridiculous the rules are. That was when he was working on a 70 cm OFDM based Digital Amateur TV thing written in verilog
On Mon, Jun 3, 2019 at 7:49 PM David Ranch amprgw@trinnet.net wrote:
Hello Guillaume,
Great to hear that you're willing to try narrower bandwidth offerings! That's a huge help to give this new mode you're working on a try. To your other point, unfortunately yes, the FCC restrictions here in the US are antiquated. Until they can be changed (the request is already been pending for YEARS), we have to live with them. Please not that it's the *symbol* rate that's limited for say 70cm. I would imagine that 70cm would be the most popular band to use in the US to experiment compared to say 33 cm or 23cm.
I had to look up the whole thing again but here is the exact FCC wording:
http://www.arrl.org/part-97-text *§97.305 Authorized emission types.*
--
UHF:
70 cm
Entire band
MCW, phone, image, RTTY, data, SS, test
(6), (8).
33 cm
Entire band
MCW, phone, image, RTTY, data, SS, test, pulse
(7), (8), and (12).
23 cm
Entire band
MCW, phone, image, RTTY, data, SS, test
(7), (8), and (12).
(f) The following standards and limitations apply to transmissions on the frequencies specified in §97.305(c) of this part.
(6) A RTTY, data or multiplexed emission using a specified digitalcode listed in §97.309(a) of this part may be transmitted. The symbol rate must not exceed 56 kilobauds. A RTTY, data or multiplexed emission using an unspecified digital code under the limitations listed in §97.309(b) of this part also may be transmitted. The authorized bandwidth is 100 kHz.
(7) A RTTY, data or multiplexed emission using a specified digital code listed in §97.309(a) of this part or an unspecified digital code under the limitations listed in §97.309(b) of this part may be transmitted.--
(8) A RTTY or data emission having designators with A, B, C, D, E,F, G, H, J or R as the first symbol; 1, 2, 7, 9 or X as the second symbol; and D or W as the third symbol is also authorized.
(12) Emission F8E may be transmitted.
--David KI6ZHD
On 06/03/2019 01:16 PM, f4hdk wrote:
Hello,
Yes, I will try to provide smaller bandwidths in the following months (or weeks?) for NPR. Probably ~180kHz, which could carry ~90kbps with 2GFSK and ~160kbps with 4GFSK (net datarate).
But I don't think that I will propose modulation parameters which could match the (very small) FCC restrictions (100kHz and 56kbaud if I remember well). This rule seems outdated to me... even if it still applies.
Do not hesitate to take a look regularly at my hackaday web-page in order to keep informed about "New Packet Radio". https://hackaday.io/project/164092-npr-new-packet-radio
73, Guillaume F4HDK
Le 03/06/2019 à 04:00, David Ranch a écrit :
Great to hear and thanks for the update Mark. Has there been any mention of supporting smaller bandwidths in the future?
--David KI6ZHD
On 06/02/2019 05:27 PM, Mark Phillips wrote:
Got a pair of these modems working! They are just running across the bench right now. I have an RPi3 and a MMDVM hotspot connected to the client (via a switch) with the master connected to a spare port on the back of my pfSense firewall. I'm using mode "22" which is 270KHz wide for about 220kbps of data bandwidth. This seems more than able to handle the serving of a web age and running the MMDVM. I also did a test in 500kbps mode using a wifi hotspot attached to the client. I was able to sustain a "wifi calling" cellphone conversation for over an hour with no issues.
For those not following the project, new firmware was released this weekend that allows tuning of the RF from 420-450MHz which is a great improvement over the EU only bandplan.
Take a look here http://g7ltt.dyndns.org:2210
Mark G7LTT/NI2O
On Tue, Mar 26, 2019 at 4:24 PM Steve L via 44Net 44net@mailman.ampr.org wrote:
In case anyone feels the need:
It's pretty easy to file a petition through the ECFS. When you go to the main ECFS page https://www.fcc.gov/ecfs/filings in "Type of filing" select "petition for rule making", and fill out the rest of the form and upload your petition.
A couple useful pages from the FCC: < https://www.publicknowledge.org/assets/uploads/blog/RP_FCCPetitiontoDeny.pdf
https://www.fcc.gov/about-fcc/rulemaking-process Here is a quick summary from the last one, three are more details on the page. *Organized comments*. *Clear explanation and support for views*. *Alternatives. * *Examples of concerns.* *Statutory limitations.*
It's also helpful to review recent amateur petitions and the FCC response. The rejections are a wealth of information on what not to do. It might be advisable to suggest RM-11392 and DA 08-1092 rejection, RM-11699 and DA 13-1918 rejection, as starting points since its somewhat related.
Don't use ham jargon, be sure sure to explain acronyms at least once in the filing, if repeated makes it easier to follow. Don't bash other amateur modes or practices. Don't use technical terms unless fully explained so a lawyer can understand, most on the Commission are non-tech types. Don't ask to ban anything, if you want that done make the case to the FCC that whatever it is is poor practice without requesting a ban......let them do it.
Do make your petition concise and to the point without a lot of rambling and legalese. Do provide a reason as to why it's a benefit to the amateur service as a whole, also in the public interest if it applies. Do have someone, with the background to understand it, proofread and comment. Do be ready for rebuttal of comments if there are any opposing....wait for the "reply to comment" period, this isn't an internet forum squabble. Keep comments/reply to civil and professional.
On Sun, Mar 24, 2019 at 3:13 PM Ron Economos via 44Net 44net@mailman.ampr.org wrote:
This keeps coming up. Has anyone ever submitted a petition for rule making to the FCC? Or are folks afraid that stirring the pot will get DATV banned on 70 cm?
Ron W6RZ
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
On Mon, 3 Jun 2019, David Ranch wrote:
(6) A RTTY, data or multiplexed emission using a specified digital code listed in ?97.309(a) of this part may be transmitted. The symbol rate must not exceed 56 kilobauds. A RTTY, data or multiplexed emission using an unspecified digital code under the limitations listed in ?97.309(b) of this part also may be transmitted. The authorized bandwidth is 100 kHz.
56 kilobauds is because the Telebit Trailblazer existed; it used OFDM and 6 "baud" carriers.
We've never pushed the limits like wireline did. We should be able to cram 33.6 kbit/s through 0-4 kHz just like the phone modems did. It was possible to achieve 14.4 kbit/s bidirectionally with modems through a full-duplex telephone patch.
Hack apart the resistor bridge, TX to modulator, RX to demodulator, send the command to start data, and the command to answer. It'd have to be a full-duplex link, four radios involved, but that's 33.6 kbit/s bidirectional with 175 ms of modem delay or so. Good luck finding schematics today however.
-- Kris Kirby, KE4AHR Disinformation Architect, Systems Mangler, & Network Mismanager
On Tue, Jun 04, 2019 at 11:58:04PM +0000, Kris Kirby wrote:
56 kilobauds is because the Telebit Trailblazer existed; it used OFDM and 6 "baud" carriers.
We've never pushed the limits like wireline did. We should be able to cram 33.6 kbit/s through 0-4 kHz just like the phone modems did. It was possible to achieve 14.4 kbit/s bidirectionally with modems through a full-duplex telephone patch.
Hack apart the resistor bridge, TX to modulator, RX to demodulator, send the command to start data, and the command to answer. It'd have to be a full-duplex link, four radios involved, but that's 33.6 kbit/s bidirectional with 175 ms of modem delay or so. Good luck finding schematics today however.
Back in the day, I asked one of the Telebit engineers about doing something like that, and he told me two interesting points to consider: At least one model of the Trailblazer was jumperable to make it a four-wire circuit compatable device - in other words, separate receive and transmit. But he said he didn't think it would work very well because the signal-to-noise ratio and phase stability of the typical radio circuit were vastly inferior to telephone circuits. He did admit it would be an interesting experiment. As far as I know, no one ever tried it. - Brian
Mark,
I hope you are also taking the time to drop the ARRL a line.
There is still about another 30 days before they supposedly do something, which of course doesn't mean the FCC will.
The 90 day pause was so the league could active discussions with all interested parties.
http://www.arrl.org/news/fcc-agrees-to-90-day-pause-in-consideration-of-wt-d...
And WT-239 was titled "Amateur Radio Service Rules To Permit Greater Flexibility in Data Communications" from 2016
Steve, KB9MWR
On Sun, Jun 2, 2019 at 7:30 PM Mark Phillips g7ltt@g7ltt.com wrote:
Got a pair of these modems working! They are just running across the bench right now. I have an RPi3 and a MMDVM hotspot connected to the client (via a switch) with the master connected to a spare port on the back of my pfSense firewall. I'm using mode "22" which is 270KHz wide for about 220kbps of data bandwidth. This seems more than able to handle the serving of a web age and running the MMDVM. I also did a test in 500kbps mode using a wifi hotspot attached to the client. I was able to sustain a "wifi calling" cellphone conversation for over an hour with no issues.
For those not following the project, new firmware was released this weekend that allows tuning of the RF from 420-450MHz which is a great improvement over the EU only bandplan.
Take a look here http://g7ltt.dyndns.org:2210
Mark G7LTT/NI2O
On Tue, Mar 26, 2019 at 4:24 PM Steve L via 44Net 44net@mailman.ampr.org wrote:
In case anyone feels the need:
It's pretty easy to file a petition through the ECFS. When you go to the main ECFS page https://www.fcc.gov/ecfs/filings in "Type of filing" select "petition for rule making", and fill out the rest of the form and upload your petition.
A couple useful pages from the FCC: < https://www.publicknowledge.org/assets/uploads/blog/RP_FCCPetitiontoDeny.pdf
https://www.fcc.gov/about-fcc/rulemaking-process Here is a quick summary from the last one, three are more details on the page. *Organized comments*. *Clear explanation and support for views*. *Alternatives. * *Examples of concerns.* *Statutory limitations.*
It's also helpful to review recent amateur petitions and the FCC response. The rejections are a wealth of information on what not to do. It might be advisable to suggest RM-11392 and DA 08-1092 rejection, RM-11699 and DA 13-1918 rejection, as starting points since its somewhat related.
Don't use ham jargon, be sure sure to explain acronyms at least once in the filing, if repeated makes it easier to follow. Don't bash other amateur modes or practices. Don't use technical terms unless fully explained so a lawyer can understand, most on the Commission are non-tech types. Don't ask to ban anything, if you want that done make the case to the FCC that whatever it is is poor practice without requesting a ban......let them do it.
Do make your petition concise and to the point without a lot of rambling and legalese. Do provide a reason as to why it's a benefit to the amateur service as a whole, also in the public interest if it applies. Do have someone, with the background to understand it, proofread and comment. Do be ready for rebuttal of comments if there are any opposing....wait for the "reply to comment" period, this isn't an internet forum squabble. Keep comments/reply to civil and professional.
On Sun, Mar 24, 2019 at 3:13 PM Ron Economos via 44Net 44net@mailman.ampr.org wrote:
This keeps coming up. Has anyone ever submitted a petition for rule making to the FCC? Or are folks afraid that stirring the pot will get DATV banned on 70 cm?
Ron W6RZ
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Yes, digital image (digital TV) is considered differently under the rules.
An STA would be the way to get an experimental group to prove it out and then submit a report and proposal.
Though 33 cm doesn't have this limitation and the chip used in the design should support it.
On Sun, Mar 24, 2019 at 12:11 PM Mark Phillips g7ltt@g7ltt.com wrote:
I had another thought about the bandwidth.
Why can digital ATV get away with it and we cannot? Their data rates get up to mbps. They justify it by calling it "TV" rather than data.
On Sun, Mar 24, 2019 at 2:52 PM Mark Phillips g7ltt@g7ltt.com wrote:
We keep hitting this bandwidth wall. I say we should just ignore it. We are never gonna get a change if we don't show the need for it.
On Sun, Mar 24, 2019 at 2:36 PM K7VE - John k7ve@k7ve.org wrote:
I note that at the advertised bit rates, the OBW (occupied bandwidth)
may
exceed US Regulations for 70cm. However, the chip used, is also claimed to support 33cm.
I am interested in the new packet protocol proposed by the project. Even at a lower bps on 70cm (for the US), and full rate at 33cm, this has real potential for mid-tier data communications.
CFR 47 Part 97.307 (f) 6
On Sun, Mar 24, 2019 at 4:05 AM f4hdk f4hdk@free.fr wrote:
Hello,
I am Guillaume, callsign F4HDK, a french amateur-radio operator,
and a
hacker-maker. I would like to share with you my last project : NPR (New Packet
Radio).
All documentation is provided here : https://hackaday.io/project/164092-npr-new-packet-radio
This solution can transport bi directional IP trafic over 70cm radio links, in a 'point to multipoint' topology, at datarate up to
500kbps.
This can be used to increase the range of existing HSMM-Hamnet
networks,
at lower datarates. It's designed for "access", not backbone, and not designed for H24
use.
Its is 100% open-source.
Do not hesitate to ask me questions about it. I hope it will interest some people here.
73, Guillaume F4HDK
John D. Hays K7VE http://k7ve.org/blog http://twitter.com/#!/john_hays http://www.facebook.com/john.d.hays _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Mark,
I don't mean to bore all our non US friends with our silly and out dated regulations here in the US, so I'll try and keep this brief. The simple rule modification that Ron points out would solve the problem for this application. (Anyone feel free to log into the FCC and create the petition.) I have bigger dreams of regulatory reform, though maybe that isn't the way to get anywhere...
I have fundamental problems that we have to classify our emissions by how we use them rather than purely technical technical parameters. This is why while there is a data portion to all D-Star radios (not just the 1.2 GHz), they are mostly used for voice (even though it's "digital" voice. So it's classified a "phone". Just like DMR, and the like are "phone?" And digital ATV (for the few that even use ATV these days), while obviously transported as data is classified as "Image"
Spread Spectrum, Phone, Image Data.. which is it? Depending on which it is, certain rules apply. And obviously "data" has a bandwidth and symbol rate restriction, where as Image and Spread Spectrum do not.
So if you have problems with the bandwidth restriction for data, you ask yourself what could I do to classify this as some other emission type.
And while you are pondering that, ponder why this foolishness still exists.. Then fire off some emails to Connecticut.
Honestly I expect more comprehensive petitions from the League than what they proposed in 2013. I have no problem with Individuals creating narrow scoped petitions that focus on their own uses/applications etc. But as an organization that is supposed to represent the hobby as a whole, that 2013 League petition was obviously focused on Pactor and was unacceptable to me.
On Sun, Mar 24, 2019 at 2:11 PM Mark Phillips g7ltt@g7ltt.com wrote:
I had another thought about the bandwidth.
Why can digital ATV get away with it and we cannot? Their data rates get up to mbps. They justify it by calling it "TV" rather than data.
On Sun, Mar 24, 2019 at 2:52 PM Mark Phillips g7ltt@g7ltt.com wrote:
We keep hitting this bandwidth wall. I say we should just ignore it. We are never gonna get a change if we don't show the need for it.
On Sun, Mar 24, 2019 at 2:36 PM K7VE - John k7ve@k7ve.org wrote:
I note that at the advertised bit rates, the OBW (occupied bandwidth) may exceed US Regulations for 70cm. However, the chip used, is also claimed to support 33cm.
I am interested in the new packet protocol proposed by the project. Even at a lower bps on 70cm (for the US), and full rate at 33cm, this has real potential for mid-tier data communications.
CFR 47 Part 97.307 (f) 6
On Sun, Mar 24, 2019 at 4:05 AM f4hdk f4hdk@free.fr wrote:
Hello,
I am Guillaume, callsign F4HDK, a french amateur-radio operator, and a hacker-maker. I would like to share with you my last project : NPR (New Packet
Radio).
All documentation is provided here : https://hackaday.io/project/164092-npr-new-packet-radio
This solution can transport bi directional IP trafic over 70cm radio links, in a 'point to multipoint' topology, at datarate up to 500kbps. This can be used to increase the range of existing HSMM-Hamnet
networks,
at lower datarates. It's designed for "access", not backbone, and not designed for H24
use.
Its is 100% open-source.
Do not hesitate to ask me questions about it. I hope it will interest some people here.
73, Guillaume F4HDK
John D. Hays K7VE http://k7ve.org/blog http://twitter.com/#!/john_hays http://www.facebook.com/john.d.hays _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Hello from Argentina,
You are not boring non US friends, but in fact pushing forward the future, which is what we hams should do.
Several years ago, we requested in Argentina to our local FCC authorities, to have a data bandwith of 300 KHz on 70cm, due we wanted to experiment high speed packet.
After several presentations, result was our FCC granted, aprooved and published on government papers and local regulations the following:
Considerando que AMSAT ARGENTINA ha solicitado reemplazar en el Plan de Bandas citado los anchos de banda de 12 kHz para Digimodos por 200 y 300 kHz en las bandas de 1,25 m y 70 cm respectivamente, resulta factible dar curso a dicha solicitud.
'Considering that AMSAT ARGENTINA has requested to replace the bandwidth of 12 kHz for Digimodes for 200 and 300 kHz in the bands of 1.25 m and 70 cm in the aforementioned Band Plan, it is feasible to proceed with this request.'
Perhaps this requirement and its approval could be useful to continue with the proposals to your FCC. Wishing good luck.
If it could be useful, our presentation document (in spanish) is at: http://amsat.org.ar/Amsat-Solicitud-Anchos-de-banda.pdf
Best 73, LU7ABF, Pedro Converso.
PD: We make succesful experiences using 115 Kbps, Manchester on 1.25m even before year 2000.
On 3/24/19, Steve L via 44Net 44net@mailman.ampr.org wrote:
Mark,
I don't mean to bore all our non US friends with our silly and out dated regulations here in the US, so I'll try and keep this brief. The simple rule modification that Ron points out would solve the problem for this application. (Anyone feel free to log into the FCC and create the petition.) I have bigger dreams of regulatory reform, though maybe that isn't the way to get anywhere...
I have fundamental problems that we have to classify our emissions by how we use them rather than purely technical technical parameters. This is why while there is a data portion to all D-Star radios (not just the 1.2 GHz), they are mostly used for voice (even though it's "digital" voice. So it's classified a "phone". Just like DMR, and the like are "phone?" And digital ATV (for the few that even use ATV these days), while obviously transported as data is classified as "Image"
Spread Spectrum, Phone, Image Data.. which is it? Depending on which it is, certain rules apply. And obviously "data" has a bandwidth and symbol rate restriction, where as Image and Spread Spectrum do not.
So if you have problems with the bandwidth restriction for data, you ask yourself what could I do to classify this as some other emission type.
And while you are pondering that, ponder why this foolishness still exists.. Then fire off some emails to Connecticut.
Honestly I expect more comprehensive petitions from the League than what they proposed in 2013. I have no problem with Individuals creating narrow scoped petitions that focus on their own uses/applications etc. But as an organization that is supposed to represent the hobby as a whole, that 2013 League petition was obviously focused on Pactor and was unacceptable to me.
On Sun, Mar 24, 2019 at 2:11 PM Mark Phillips g7ltt@g7ltt.com wrote:
I had another thought about the bandwidth.
Why can digital ATV get away with it and we cannot? Their data rates get up to mbps. They justify it by calling it "TV" rather than data.
On Sun, Mar 24, 2019 at 2:52 PM Mark Phillips g7ltt@g7ltt.com wrote:
We keep hitting this bandwidth wall. I say we should just ignore it. We are never gonna get a change if we don't show the need for it.
On Sun, Mar 24, 2019 at 2:36 PM K7VE - John k7ve@k7ve.org wrote:
I note that at the advertised bit rates, the OBW (occupied bandwidth) may exceed US Regulations for 70cm. However, the chip used, is also claimed to support 33cm.
I am interested in the new packet protocol proposed by the project. Even at a lower bps on 70cm (for the US), and full rate at 33cm, this has real potential for mid-tier data communications.
CFR 47 Part 97.307 (f) 6
On Sun, Mar 24, 2019 at 4:05 AM f4hdk f4hdk@free.fr wrote:
Hello,
I am Guillaume, callsign F4HDK, a french amateur-radio operator, and a hacker-maker. I would like to share with you my last project : NPR (New Packet
Radio).
All documentation is provided here : https://hackaday.io/project/164092-npr-new-packet-radio
This solution can transport bi directional IP trafic over 70cm radio links, in a 'point to multipoint' topology, at datarate up to 500kbps. This can be used to increase the range of existing HSMM-Hamnet
networks,
at lower datarates. It's designed for "access", not backbone, and not designed for H24
use.
Its is 100% open-source.
Do not hesitate to ask me questions about it. I hope it will interest some people here.
73, Guillaume F4HDK
John D. Hays K7VE http://k7ve.org/blog http://twitter.com/#!/john_hays http://www.facebook.com/john.d.hays _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Hello John,
Sure, you can use RF4463F30 modules for the 33cm band (band not available for amateur-radio here in France). But then the difficulty would be to find a good (and cheap) radio amplifier with fast TX/RX commutation times. The big avantage of my solution over 430MHz band is that you can find cheap DMR amplifier, with fast TX/RX times (less than 500 microseconds).
If you find equivalent amplifiers for 33cm band, please let us know. I would be very interested, and I will update my project!
73, Guillaume F4HDK
Le 24/03/2019 à 19:36, K7VE - John a écrit :
I note that at the advertised bit rates, the OBW (occupied bandwidth) may exceed US Regulations for 70cm. However, the chip used, is also claimed to support 33cm.
I am interested in the new packet protocol proposed by the project. Even at a lower bps on 70cm (for the US), and full rate at 33cm, this has real potential for mid-tier data communications.
CFR 47 Part 97.307 (f) 6
On Sun, Mar 24, 2019 at 4:05 AM f4hdk f4hdk@free.fr wrote:
Hello,
I am Guillaume, callsign F4HDK, a french amateur-radio operator, and a hacker-maker. I would like to share with you my last project : NPR (New Packet Radio).
All documentation is provided here : https://hackaday.io/project/164092-npr-new-packet-radio
This solution can transport bi directional IP trafic over 70cm radio links, in a 'point to multipoint' topology, at datarate up to 500kbps. This can be used to increase the range of existing HSMM-Hamnet networks, at lower datarates. It's designed for "access", not backbone, and not designed for H24 use. Its is 100% open-source.
Do not hesitate to ask me questions about it. I hope it will interest some people here.
73, Guillaume F4HDK
John D. Hays K7VE http://k7ve.org/blog http://twitter.com/#!/john_hays http://www.facebook.com/john.d.hays
Will do
On Mon, Mar 25, 2019, 11:45 f4hdk f4hdk@free.fr wrote:
Hello John,
Sure, you can use RF4463F30 modules for the 33cm band (band not available for amateur-radio here in France). But then the difficulty would be to find a good (and cheap) radio amplifier with fast TX/RX commutation times. The big avantage of my solution over 430MHz band is that you can find cheap DMR amplifier, with fast TX/RX times (less than 500 microseconds).
If you find equivalent amplifiers for 33cm band, please let us know. I would be very interested, and I will update my project!
73, Guillaume F4HDK
Le 24/03/2019 à 19:36, K7VE - John a écrit :
I note that at the advertised bit rates, the OBW (occupied bandwidth) may exceed US Regulations for 70cm. However, the chip used, is also claimed
to
support 33cm.
I am interested in the new packet protocol proposed by the project. Even
at
a lower bps on 70cm (for the US), and full rate at 33cm, this has real potential for mid-tier data communications.
CFR 47 Part 97.307 (f) 6
On Sun, Mar 24, 2019 at 4:05 AM f4hdk f4hdk@free.fr wrote:
Hello,
I am Guillaume, callsign F4HDK, a french amateur-radio operator, and a hacker-maker. I would like to share with you my last project : NPR (New Packet
Radio).
All documentation is provided here : https://hackaday.io/project/164092-npr-new-packet-radio
This solution can transport bi directional IP trafic over 70cm radio links, in a 'point to multipoint' topology, at datarate up to 500kbps. This can be used to increase the range of existing HSMM-Hamnet
networks,
at lower datarates. It's designed for "access", not backbone, and not designed for H24 use. Its is 100% open-source.
Do not hesitate to ask me questions about it. I hope it will interest some people here.
73, Guillaume F4HDK
John D. Hays K7VE http://k7ve.org/blog http://twitter.com/#!/john_hays http://www.facebook.com/john.d.hays
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Thanks for your feedback.
All the documentation about the project is directly on the hackaday page, follow the links on the table : https://hackaday.io/project/164092-npr-new-packet-radio
It's not a Dorji radio. All the components that I have used have fast TX/RX commutation times : less than 500 microseconds in total. * 433MHz ISM band module (RF 4463 F30 from Nice RF) * DMR-compatible radio amplifier (VR-P25D from Vero-Telecom)
73, Guillaume F4HDK
Le 24/03/2019 à 19:16, Mark Phillips a écrit :
I want this!!!!!!
I note that you have used a Dorji radio module modules which have variable rise times in the order of over half a second. How did you overcome this?
Got a link to the project?
Mark
On Sun, Mar 24, 2019 at 4:05 AM f4hdk f4hdk@free.fr wrote:
Hello,
I am Guillaume, callsign F4HDK, a french amateur-radio operator, and a hacker-maker. I would like to share with you my last project : NPR (New Packet Radio).
All documentation is provided here : https://hackaday.io/project/164092-npr-new-packet-radio
This solution can transport bi directional IP trafic over 70cm radio links, in a 'point to multipoint' topology, at datarate up to 500kbps. This can be used to increase the range of existing HSMM-Hamnet networks, at lower datarates. It's designed for "access", not backbone, and not designed for H24 use. Its is 100% open-source.
Do not hesitate to ask me questions about it. I hope it will interest some people here.
73, Guillaume F4HDK _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Il giorno dom 24 mar 2019 alle ore 10:19 f4hdk f4hdk@free.fr ha scritto:
I would like to share with you my last project : NPR (New Packet Radio).
All documentation is provided here : https://hackaday.io/project/164092-npr-new-packet-radio
This solution can transport bi directional IP trafic over 70cm radio links, in a 'point to multipoint' topology, at datarate up to 500kbps. This can be used to increase the range of existing HSMM-Hamnet networks, at lower datarates. It's designed for "access", not backbone, and not designed for H24 use. Its is 100% open-source.
Very interesting, everithing over radio is a good news for us :)
On this point I take the opportunity to notify also the slovenian (Matjaz Vidmar, S53MV) interesting NBP protocol and equipment: http://lea.hamradio.si/~s53mv/nbp/nbp.html
and the history of AX.25 in Slovenia (and neighbouring regions like Nord West of Italy): http://lea.hamradio.si/~s53mv/nbp/ax25.html
Unfortunately I didn't hear anything about NBP for the last two hears...
Hi Guillaume,
Le 24/03/2019 à 09:05, f4hdk a écrit :
I would like to share with you my last project : NPR (New Packet Radio).
Wow : What an impressive work !
Maybe the key of success is a low-cost and easy to build modem. Your approach of using existing modules, and the compatibility with DMR amplifiers, seem to be very good things.
About the protocol itself, it may require some tunings or improvements, but it's just a matter of code. We'll be able to discuss about it here. This hardware platform, coupled with a Raspberry Pi, may allow lots of experiments...
And the most important thing for me : * Thank you very much for putting the whole project in open-source ! *
-- We have many, many things on the go here, but I'll be happy to experiment that ASAP.
73 de TK1BI
+1 on the open source thing. We'll be able to keep up with hardware availability that way. already the WizNet board is EOL here in the US but the chip on it is still in production.
Mark
On Mon, Mar 25, 2019 at 1:09 PM Toussaint OTTAVI t.ottavi@bc-109.com wrote:
Hi Guillaume,
Le 24/03/2019 à 09:05, f4hdk a écrit :
I would like to share with you my last project : NPR (New Packet Radio).
Wow : What an impressive work !
Maybe the key of success is a low-cost and easy to build modem. Your approach of using existing modules, and the compatibility with DMR amplifiers, seem to be very good things.
About the protocol itself, it may require some tunings or improvements, but it's just a matter of code. We'll be able to discuss about it here. This hardware platform, coupled with a Raspberry Pi, may allow lots of experiments...
And the most important thing for me : * Thank you very much for putting the whole project in open-source ! *
-- We have many, many things on the go here, but I'll be happy to experiment that ASAP.
73 de TK1BI _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
The spec sheet for the Ethernet module if anyone is interested. Mouser has 25 in stock.
https://www.mouser.com/datasheet/2/272/eth-wiz-click-manual-v100-1487276.pdf
Mark
On Mon, Mar 25, 2019 at 1:26 PM Mark Phillips g7ltt@g7ltt.com wrote:
+1 on the open source thing. We'll be able to keep up with hardware availability that way. already the WizNet board is EOL here in the US but the chip on it is still in production.
Mark
On Mon, Mar 25, 2019 at 1:09 PM Toussaint OTTAVI t.ottavi@bc-109.com wrote:
Hi Guillaume,
Le 24/03/2019 à 09:05, f4hdk a écrit :
I would like to share with you my last project : NPR (New Packet Radio).
Wow : What an impressive work !
Maybe the key of success is a low-cost and easy to build modem. Your approach of using existing modules, and the compatibility with DMR amplifiers, seem to be very good things.
About the protocol itself, it may require some tunings or improvements, but it's just a matter of code. We'll be able to discuss about it here. This hardware platform, coupled with a Raspberry Pi, may allow lots of experiments...
And the most important thing for me : * Thank you very much for putting the whole project in open-source ! *
-- We have many, many things on the go here, but I'll be happy to experiment that ASAP.
73 de TK1BI _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
I envisioned this and did additional research years ago and tabled it due to some of the lack of interest.
Although I have a working proof of concept that works via Ethernet and didn’t pursue adding the uhf mesh radio.
Maybe it’s time to dust off the old code for this.
Original post here https://forums.qrz.com/index.php?threads/thoughts-needed-open-digital-voice-...
See the pdf attachment on that first post for a simple block diagram.
Totally doable with off the shelf hardware and open source software.
Best Elias Kd5jfe
Could the source be put into github so that updates are available?
On Mon, Mar 25, 2019 at 10:12 AM Toussaint OTTAVI t.ottavi@bc-109.com wrote:
Hi Guillaume,
Le 24/03/2019 à 09:05, f4hdk a écrit :
I would like to share with you my last project : NPR (New Packet Radio).
Wow : What an impressive work !
Maybe the key of success is a low-cost and easy to build modem. Your approach of using existing modules, and the compatibility with DMR amplifiers, seem to be very good things.
About the protocol itself, it may require some tunings or improvements, but it's just a matter of code. We'll be able to discuss about it here. This hardware platform, coupled with a Raspberry Pi, may allow lots of experiments...
And the most important thing for me : * Thank you very much for putting the whole project in open-source ! *
--
------------------------------ John D. Hays K7VE http://k7ve.org/blog http://twitter.com/#!/john_hays http://www.facebook.com/john.d.hays
Sorry but I must say it in french ;-)
Félicitation superbe travail!
De Pierre VE2PF
________________________________ De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de f4hdk f4hdk@free.fr Envoyé : 24 mars 2019 04:05 À : 44net@mailman.ampr.org Objet : [44net] Hamnet over 70cm : NPR (New Packet Radio)
Hello,
I am Guillaume, callsign F4HDK, a french amateur-radio operator, and a hacker-maker. I would like to share with you my last project : NPR (New Packet Radio).
All documentation is provided here : https://hackaday.io/project/164092-npr-new-packet-radio
This solution can transport bi directional IP trafic over 70cm radio links, in a 'point to multipoint' topology, at datarate up to 500kbps. This can be used to increase the range of existing HSMM-Hamnet networks, at lower datarates. It's designed for "access", not backbone, and not designed for H24 use. Its is 100% open-source.
Do not hesitate to ask me questions about it. I hope it will interest some people here.
73, Guillaume F4HDK _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Discussion on Hacker News.
https://news.ycombinator.com/item?id=19482786
Ron W6RZ
On 3/24/19 01:05, f4hdk wrote:
Hello,
I am Guillaume, callsign F4HDK, a french amateur-radio operator, and a hacker-maker. I would like to share with you my last project : NPR (New Packet Radio).
All documentation is provided here : https://hackaday.io/project/164092-npr-new-packet-radio
This solution can transport bi directional IP trafic over 70cm radio links, in a 'point to multipoint' topology, at datarate up to 500kbps. This can be used to increase the range of existing HSMM-Hamnet networks, at lower datarates. It's designed for "access", not backbone, and not designed for H24 use. Its is 100% open-source.
Do not hesitate to ask me questions about it. I hope it will interest some people here.
73, Guillaume F4HDK _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net