24 Mar
2019
24 Mar
'19
3:05 p.m.
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
25 Mar
25 Mar
1:14 a.m.
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.
2:34 a.m.
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.
8:27 a.m.
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
9:45 a.m.
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
2:30 p.m.
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
26 Mar
26 Mar
2:36 a.m.
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
2:50 a.m.
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
5:57 a.m.
OK. Thanks!MichaelSent from my Verizon, Samsung Galaxy smartphone
-------- Original message --------From: f4hdk <f4hdk(a)free.fr> Date: 3/25/19 12:50
(GMT-08:00) To: 44net(a)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
6:11 a.m.
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(a)free.fr> Date: 3/25/19 12:50
(GMT-08:00) To: 44net(a)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
25 Mar
25 Mar
1:16 a.m.
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(a)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(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
1:36 a.m.
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(a)free.fr> wrote:
------------------------------
John D. Hays
K7VE
<http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
<http://www.facebook.com/john.d.hays>
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
1:52 a.m.
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(a)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
------------------------------
John D. Hays
K7VE
<http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
<http://www.facebook.com/john.d.hays>
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
On Sun, Mar 24, 2019 at 4:05 AM f4hdk <f4hdk(a)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
2:09 a.m.
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(a)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(a)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
------------------------------
John D. Hays
K7VE
<http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
<http://www.facebook.com/john.d.hays>
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
On Sun, Mar 24, 2019 at 4:05 AM f4hdk <f4hdk(a)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
3:11 a.m.
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(a)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(a)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
>>
4:45 a.m.
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(a)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(a)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(a)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(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
5:17 a.m.
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(a)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:
_________________________________________
44Net mailing list
44Net(a)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(a)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(a)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(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
27 Mar
27 Mar
3:24 a.m.
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(a)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
3 Jun
3 Jun
7:27 a.m.
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(a)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(a)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(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
9 a.m.
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(a)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(a)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
9:45 a.m.
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-t…
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(a)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(a)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(a)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(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
4 Jun
4 Jun
3:16 a.m.
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(a)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(a)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
4:08 a.m.
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(a)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 :
_________________________________________
44Net mailing list
44Net(a)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(a)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(a)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
7:47 a.m.
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:
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net 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(a)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(a)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
11:58 a.m.
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(a)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 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 :
_________________________________________
44Net mailing list
44Net(a)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:
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net 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(a)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(a)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
5 Jun
5 Jun
6:58 a.m.
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
7:23 a.m.
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
9 Jun
9 Jun
12:53 a.m.
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-…
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(a)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(a)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(a)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(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
25 Mar
25 Mar
6:15 a.m.
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(a)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(a)g7ltt.com> wrote:
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
--
------------------------------
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(a)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(a)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(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
6:58 a.m.
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(a)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(a)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(a)k7ve.org> wrote:
_________________________________________
44Net mailing list
44Net(a)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(a)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(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
11:43 a.m.
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(a)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(a)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(a)g7ltt.com> wrote:
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
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(a)k7ve.org> wrote:
_________________________________________
44Net mailing list
44Net(a)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(a)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(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
26 Mar
26 Mar
1:42 a.m.
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(a)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>
2:13 a.m.
Will do
On Mon, Mar 25, 2019, 11:45 f4hdk <f4hdk(a)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 :
_________________________________________
44Net mailing list
44Net(a)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(a)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>
25 Mar
25 Mar
2:21 a.m.
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(a)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(a)mailman.ampr.org
> https://mailman.ampr.org/mailman/listinfo/44net
>
8:47 p.m.
Il giorno dom 24 mar 2019 alle ore 10:19 f4hdk <f4hdk(a)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...
26 Mar
26 Mar
12:09 a.m.
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
12:26 a.m.
+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(a)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(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
12:33 a.m.
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(a)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(a)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(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
12:58 a.m.
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
12:27 a.m.
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(a)bc-109.com>
wrote:
Hi Guillaume,
Le 24/03/2019 à 09:05, f4hdk a écrit :
------------------------------
John D. Hays
K7VE
<http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
<http://www.facebook.com/john.d.hays>
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 ! *
-- 
3:11 a.m.
Sorry but I must say it in french ;-)
Félicitation superbe travail!
De Pierre VE2PF
________________________________
De : 44Net <44net-bounces+petem001=hotmail.com(a)mailman.ampr.org> de la part de f4hdk
<f4hdk(a)free.fr>
Envoyé : 24 mars 2019 04:05
À : 44net(a)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(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
4:20 a.m.
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(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
2026
days inactive
2102
days old
41 comments
16 participants
participants (16)
-
Brian Kantor -
David Ranch -
Elias Basse -
f4hdk -
John D. Hays -
K7VE - John -
Kris Kirby -
Lorenzo Simoncello -
Mark Phillips -
Michael Fox -
Michael Fox - N6MEF
-
Pedro Converso -
pete M -
Ron Economos -
Steve L -
Toussaint OTTAVI