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
>>
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
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
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
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
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
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),
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,
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
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
> 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.
--
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
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
13 matches
Mail list logo