Re: [Freetel-codec2] IP protocol over FreeDV

2018-03-26 Thread Sebastien F4GRX 
hello

6lowpan can work without 802.15.4

The NuttX RTOS has a generic 6lowpan implementation for embedded ARM.

Sebastien


Le 25/03/2018 à 10:59, Stuart Longland a écrit :
> On 25/03/18 13:00, Dean H (KC4KSU) wrote:
>> It’s good to hear someone else is looking at applying 6LoWPAN to amateur
>> radio.
>>
>> I’ve studied 802.15.4 a fair bit.  I find the standard is growing beyond
>> an individual’s ability to manage.  So I distilled the 802.15.4 frame to
>> the essential pieces.  My result  is
>> not 802.15.4 compliant, but it’s much more manageable for an individual
>> to understand and write code.  My frame format will support RFC6282
>> (header compress and UDP compression).
> I don't think 6LoWPAN over Bluetooth Low Energy confirms to 802.15.4
> either.  To be honest, a IEEE 802.15.4 is never going to be practical on
> amateur radio bands, and there's nothing to say we have to confirm. :-)
>
>> My target radio is the Semtech SX127X running in LoRa
>>  mode.  That’s a Chirp Spread
>> Spectrum modulation with selectable bandwidth from 7.8 to 500 KHz.  It
>> has built-in FEC and supports payloads up to 255 Bytes.  Not enormous
>> paylods, but twice that of 802.15.4.  My first LoRa configuration is
>> (Bandwidth=250KHz, FEC code rate: 4/6, spread factor: 128).  This
>> results is a data rate around 9000 bps.
>>
>> My current status is that I have a physical layer driver working and I’m
>> building the MAC layer.  It’s time-slotted, but not channel hopping.  
>>  Time slots are 250ms to allow a full frame and an ack.  The radio
>> boards  have a GPS
>> chip and synchronize to its Pulse-Per-Second (PPS).
> Ahh, so 433MHz.  Over 1kB/sec data rates is nothing to be snorted at to
> be honest, even if it does take 250kHz of spectrum.
>
> My reasoning for using AX.25 equipment is largely because there's a lot
> of infrastructure already around.  I have two stations capable of
> operating with it, and it's widely understood.  I recognise that it's
> sub-optimal in terms of noise performance.
>
> A "FreeDV 1200" modem could conceivably run just as fast, and provide
> the long-distance hops between isolated networks via HF links.  There's
> no reason why we can't route between such networks… or even the 433MHz
> system you're proposing -- it's all IP after all. :-)
>
>> In the MAC layer, I have an extended Beacon working.  I’m experimenting
>> with what to put in the beacon at the moment.  My next endeavor is to
>> create a MAC command for simple text messages.  This is all still in
>> prototype stage.  I’m coding in Python3 on a Raspberry Pi 3.  Yes, I’m
>> getting millisecond-level accuracy with Python.  I start range-testing
>> the 1/10th Watt radio modules this weekend.  There are 1W modules if
>> this protocol proves promising.
> Sounds good.  Nothing wrong with Python, especially at the prototyping
> stage.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] IP protocol over FreeDV

2018-03-25 Thread Stuart Longland 
On 25/03/18 13:00, Dean H (KC4KSU) wrote:
> It’s good to hear someone else is looking at applying 6LoWPAN to amateur
> radio.
> 
> I’ve studied 802.15.4 a fair bit.  I find the standard is growing beyond
> an individual’s ability to manage.  So I distilled the 802.15.4 frame to
> the essential pieces.  My result  is
> not 802.15.4 compliant, but it’s much more manageable for an individual
> to understand and write code.  My frame format will support RFC6282
> (header compress and UDP compression).

I don't think 6LoWPAN over Bluetooth Low Energy confirms to 802.15.4
either.  To be honest, a IEEE 802.15.4 is never going to be practical on
amateur radio bands, and there's nothing to say we have to confirm. :-)

> My target radio is the Semtech SX127X running in LoRa
>  mode.  That’s a Chirp Spread
> Spectrum modulation with selectable bandwidth from 7.8 to 500 KHz.  It
> has built-in FEC and supports payloads up to 255 Bytes.  Not enormous
> paylods, but twice that of 802.15.4.  My first LoRa configuration is
> (Bandwidth=250KHz, FEC code rate: 4/6, spread factor: 128).  This
> results is a data rate around 9000 bps.
> 
> My current status is that I have a physical layer driver working and I’m
> building the MAC layer.  It’s time-slotted, but not channel hopping.  
>  Time slots are 250ms to allow a full frame and an ack.  The radio
> boards  have a GPS
> chip and synchronize to its Pulse-Per-Second (PPS).

Ahh, so 433MHz.  Over 1kB/sec data rates is nothing to be snorted at to
be honest, even if it does take 250kHz of spectrum.

My reasoning for using AX.25 equipment is largely because there's a lot
of infrastructure already around.  I have two stations capable of
operating with it, and it's widely understood.  I recognise that it's
sub-optimal in terms of noise performance.

A "FreeDV 1200" modem could conceivably run just as fast, and provide
the long-distance hops between isolated networks via HF links.  There's
no reason why we can't route between such networks… or even the 433MHz
system you're proposing -- it's all IP after all. :-)

> In the MAC layer, I have an extended Beacon working.  I’m experimenting
> with what to put in the beacon at the moment.  My next endeavor is to
> create a MAC command for simple text messages.  This is all still in
> prototype stage.  I’m coding in Python3 on a Raspberry Pi 3.  Yes, I’m
> getting millisecond-level accuracy with Python.  I start range-testing
> the 1/10th Watt radio modules this weekend.  There are 1W modules if
> this protocol proves promising.

Sounds good.  Nothing wrong with Python, especially at the prototyping
stage.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] IP protocol over FreeDV

2018-03-24 Thread Dean H (KC4KSU) 
Stuart,

It’s good to hear someone else is looking at applying 6LoWPAN to amateur radio.

I’ve studied 802.15.4 a fair bit.  I find the standard is growing beyond an 
individual’s ability to manage.  So I distilled the 802.15.4 frame to the 
essential pieces.  My result  is not 802.15.4 
compliant, but it’s much more manageable for an individual to understand and 
write code.  My frame format will support RFC6282 (header compress and UDP 
compression).

My target radio is the Semtech SX127X running in LoRa 
 mode.  That’s a Chirp Spread Spectrum 
modulation with selectable bandwidth from 7.8 to 500 KHz.  It has built-in FEC 
and supports payloads up to 255 Bytes.  Not enormous paylods, but twice that of 
802.15.4.  My first LoRa configuration is (Bandwidth=250KHz, FEC code rate: 
4/6, spread factor: 128).  This results is a data rate around 9000 bps.

My current status is that I have a physical layer driver working and I’m 
building the MAC layer.  It’s time-slotted, but not channel hopping.Time 
slots are 250ms to allow a full frame and an ack.  The radio boards 
 have a GPS chip and 
synchronize to its Pulse-Per-Second (PPS).

In the MAC layer, I have an extended Beacon working.  I’m experimenting with 
what to put in the beacon at the moment.  My next endeavor is to create a MAC 
command for simple text messages.  This is all still in prototype stage.  I’m 
coding in Python3 on a Raspberry Pi 3.  Yes, I’m getting millisecond-level 
accuracy with Python.  I start range-testing the 1/10th Watt radio modules this 
weekend.  There are 1W modules if this protocol proves promising.

regards,

!!Dean
KC4KSU


> On Mar 24, 2018, at 4:57 PM, Stuart Longland  
> wrote:
> 
> On 25/03/18 06:25, Bruce Perens wrote:
>> FreeDV voice packets are around 7 bytes per 40 milliseconds. Even a
>> single IPV6 /address /is twice the size, not to mention the rest of the
>> header. So, realistic expectations are called for. Header compression is
>> helpful. Retransmission of a TCP packet could easily be a 1500 or more
>> byte repeat, taking most of a second. The best mix of FEC to reduce
>> repeats while minimizing overhead is still open for your research.
> 
> Actually, I have been looking at how 6LoWPAN does things.  In
> particular, I've been working with OpenThread at work, and considered
> rejigging that to work within AX.25 UI frames which could be transmitted
> with existing AX.25 hardware for FM, or utilise the FreeDV modem for SSB.
> 
> 6LoWPAN ordinarily runs over IEEE 802.15.4.  There, they have a 128-byte
> limit on link-layer frames, and a radio network of nodes where not all
> nodes can directly communicate.
> 
> For nodes within the mesh, they actually use a shortened address to
> abbreviate the IP address to help compress the header down, and the
> protocols typically used over 6LoWPAN are typically geared to keep the
> packet size down (e.g. CoAP instead of HTTP).  If you do send a big
> packet, it gets fragmented.
> 
> I don't think there's repetition of a single frame within that segment,
> so it'd be up to upper layers to re-send the lot.  Forward erasure
> coding would help a lot there as the probability of us losing a packet
> is so much higher.
> 
> Thread is officially supposed to work over 2.4GHz, but there's nothing
> to suggest it couldn't work on HF.  We just have to do our own modem to
> replace 802.15.4, and rejig the crypto so that shared keys are used to
> authenticate (a message integrity code) instead of encrypt.
> 
> In short though, I think it could work.
> -- 
> Stuart Longland (aka Redhatter, VK4MSL)
> 
> I haven't lost my mind...
>  ...it's backed up on a tape somewhere.
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Freetel-codec2 mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] IP protocol over FreeDV

2018-03-24 Thread Jeroen Vreeken 
Years ago I used TCP over 1200bps AX25 connections using UI frames.
It worked quite well as long as you don't expect to much. Receiving an
email (back when emails were just some ascii text) worked fine, but
forget about protocols like HTTP.

The current datalink code in freedv can compress headers (the ethernet
ones) to some degree, especially if you transmit to the broadcast address.
In combination with voice it makes more sense to use protocols with high
data density and relativly low information rates. For example with FPRS
I don't use the extra IP layer and can transmit identification together
with position and altitude in just three frames or 120ms.


On 03/24/2018 09:25 PM, Bruce Perens wrote:
> FreeDV voice packets are around 7 bytes per 40 milliseconds. Even a
> single IPV6 /address /is twice the size, not to mention the rest of
> the header. So, realistic expectations are called for. Header
> compression is helpful. Retransmission of a TCP packet could easily be
> a 1500 or more byte repeat, taking most of a second. The best mix of
> FEC to reduce repeats while minimizing overhead is still open for your
> research.
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
> ___
> Freetel-codec2 mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] IP protocol over FreeDV

2018-03-24 Thread Stuart Longland 
On 25/03/18 06:25, Bruce Perens wrote:
> FreeDV voice packets are around 7 bytes per 40 milliseconds. Even a
> single IPV6 /address /is twice the size, not to mention the rest of the
> header. So, realistic expectations are called for. Header compression is
> helpful. Retransmission of a TCP packet could easily be a 1500 or more
> byte repeat, taking most of a second. The best mix of FEC to reduce
> repeats while minimizing overhead is still open for your research.

Actually, I have been looking at how 6LoWPAN does things.  In
particular, I've been working with OpenThread at work, and considered
rejigging that to work within AX.25 UI frames which could be transmitted
with existing AX.25 hardware for FM, or utilise the FreeDV modem for SSB.

6LoWPAN ordinarily runs over IEEE 802.15.4.  There, they have a 128-byte
limit on link-layer frames, and a radio network of nodes where not all
nodes can directly communicate.

For nodes within the mesh, they actually use a shortened address to
abbreviate the IP address to help compress the header down, and the
protocols typically used over 6LoWPAN are typically geared to keep the
packet size down (e.g. CoAP instead of HTTP).  If you do send a big
packet, it gets fragmented.

I don't think there's repetition of a single frame within that segment,
so it'd be up to upper layers to re-send the lot.  Forward erasure
coding would help a lot there as the probability of us losing a packet
is so much higher.

Thread is officially supposed to work over 2.4GHz, but there's nothing
to suggest it couldn't work on HF.  We just have to do our own modem to
replace 802.15.4, and rejig the crypto so that shared keys are used to
authenticate (a message integrity code) instead of encrypt.

In short though, I think it could work.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] IP protocol over FreeDV

2018-03-24 Thread Albert Cahalan 
On 3/24/18, glen english  wrote:

> If a whole word is lost, if the output of the decoder is silent, then it
> is not possible to know if a word was missed, or if the word was never
> voiced ! In analog, you might hear a noise burst and you would be aware
> that some of the communication was lost.

Adding that noise burst should be easy. Perhaps the specification
should insist that decoders do this.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] IP protocol over FreeDV

2018-03-24 Thread glen english 

The whole idea of Codec2 was to REDUCE bit rate and redundancy.
So, do what you can with structure first before adding extra stuff.

I think what you need to deal with packet loss depends on the loss 
mechanism and the communications grade.


If you randomly lose a packet (7 bytes over 40mS), then maybe that is 
tolerable, your brain can figure it out. Perhaps a maximum likelihood 
algorthm might be able to better guess what ws missed and reconstruct
Also, if a shorter minimum time-slice of 10mS compared to 40 mS was 
used, this might provide better voice performance in marginal conditions 
as less was lost. But this will be at a higher bit rate ! (the higher 
rate codec2 modes use shorter time slice) .


If you lose a whole word (say 30 packets) ,that may affect the ability 
to communicate


- if it is emergency communication, that lost word may be very 
important, so you must provide for the delivery


- if it is coversational, this may be acceptable.

Losing a whole word (sat 1.2 seconds) is a big ask for the communication 
system because if there is a repeat, there will need to be overhead 
aside to catch up.


I have experimented with 'fast catchup' with codec2 by increasing the 
output sample  rate by 10% in order to catchup for a delay in getting 
all the data, and catching back up to real time.


This is the problem with digital codec communications.

If a whole word is lost, if the output of the decoder is silent, then it 
is not possible to know if a word was missed, or if the word was never 
voiced ! In analog, you might hear a noise burst and you would be aware 
that some of the communication was lost.






--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] IP protocol over FreeDV

2018-03-24 Thread Bruce Perens 
FreeDV voice packets are around 7 bytes per 40 milliseconds. Even a single
IPV6 *address *is twice the size, not to mention the rest of the header.
So, realistic expectations are called for. Header compression is helpful.
Retransmission of a TCP packet could easily be a 1500 or more byte repeat,
taking most of a second. The best mix of FEC to reduce repeats while
minimizing overhead is still open for your research.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] IP protocol over FreeDV

2018-03-24 Thread Albert Cahalan 
On 3/24/18, Steve  wrote:

> IP is a packet protocol which requires some form of ARQ. So using the
> modem would require a completely new API to mechanise that.

No, this causes terrible interactions with TCP flow control.
TCP already has support for retransmission and congestion
control, and it relies on packet loss and packet arrival timing.
Adding an abstraction layer will damage this needed feedback.

It might be reasonable to automatically adjust the level of error
correction and the time window over which it occurs, though there
might still be bad interactions with TCP flow control.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] IP protocol over FreeDV

2018-03-24 Thread Sebastien Van Cauwenberghe 
2018-03-24 17:11 GMT+01:00 Steve :

> > I assume it would be as simple as replacing the voice payload with IP
> datagrams.
>
> IP is a packet protocol which requires some form of ARQ. So using the
> modem would require a completely new API to mechanise that.


or not. You can just push data onto the channel and accept loss in the case
of UDP over IP. TCP is designed for unreliable channel anyways so no issue
there. I would think that ARQ can be detrimental in the case you want to
use TCP/IP as it can cause a behavior similar to TCP over TCP.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] IP protocol over FreeDV

2018-03-24 Thread Steve 
> I assume it would be as simple as replacing the voice payload with IP 
> datagrams.

IP is a packet protocol which requires some form of ARQ. So using the
modem would require a completely new API to mechanise that.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] IP protocol over FreeDV

2018-03-24 Thread Jeroen Vreeken 
I have send IP packets with 2400A, 2400B and 800XA. Those modes have a
sync word in each frame that is used to switch between data and voice
frames. (And works out of the box with recent codec2 versions).
It wouldn't be hard to send data with the other modems as well (as they
are also just frames with bits) however there currently is no way to
distinguish between voice and data, that would have to be selected manually.

Regards,
Jeroen


On 03/24/2018 04:24 PM, Adrian Musceac wrote:
> Hi all,
>
> Has anyone attempted to send IP protocol on HF using FreeDV? I assume
> it would be as simple as replacing the voice payload with IP
> datagrams. I have a working TCP/IP modem on VHF, however it has lower
> weak signal performance than FreeDV.
>
>
> Regards,
> Adrian
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Freetel-codec2 mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2