New on this

New on this

[Marc Marí]

Some friends and I are trying to develop an application using AX.25
encoding, but not in standard situation.

It is intended to not use a TNC, and do everything by software, except
the transceiver itself, and by now, the transceiver can send data (not
AX.25, but plain data)

So now, we want to implement AX.25, so we can communicate with a
reciver which uses a TNC31. We've been looking a lot of documentation,
but we have not been able to determine what part of all the package
work will have to be done by hand.

We didn't configure AX25 yet, but we have the thought that what AX25

So, we will have to do by hand the data whitening and scrambling
needed for the TNC?

will return will be the data with the headers and CRC encapsulated in
KISS. Is that true?
Do you know any way to simplify all the process for a all-software transmission?

We are all a bit lost, and a bit of help would be very appreciated

Thank you in advance!

Re: SPAM: New on this

[echicken]

On Thu, Apr 4, 2013 at 6:03 PM, Marc Marí <5.markmb.5@gmail.com> wrote:
> So now, we want to implement AX.25, so we can communicate with a
> reciver which uses a TNC31. We've been looking a lot of documentation,
> but we have not been able to determine what part of all the package
> work will have to be done by hand.
>
> So, we will have to do by hand the data whitening and scrambling
> needed for the TNC?
>
> will return will be the data with the headers and CRC encapsulated in
> KISS. Is that true?
> Do you know any way to simplify all the process for a all-software transmission?

Hi Marc,

I recently wrote an implementation of AX.25 and the host-side portion
of the KISS protocol, and discovered that the KISS specification
leaves a few things unclear.  From what I've observed and been told by
some more knowledgeable people, the KISS TNC is responsible for:

- Adding the Frame Check Sequence to outgoing packets, as well as for
discarding incoming packets with an invalid FCS.

- Adding start & stop flags to outgoing packets, stripping them from
incoming packets

- Interframe time fill (per http://www.tapr.org/pub_ax25.html#2.2.11)

I suspect that the KISS TNC is also meant to take care of bit stuffing
(per http://www.tapr.org/pub_ax25.html#2.2.6) to prevent erroneous
flags being sent, but I haven't taken the time to confirm this yet.

So if you do end up using a KISS interface (a TNC in KISS mode, or
something like Soundmodem) between computer and transceiver, you can
leave these few duties for the TNC to perform.  While every KISS-mode
TNC I've tested thus far has behaved this way, it's possible that
there are some out there which do not - the fact that the spec does
not spell this out leaves room for interpretation.

Is there any place I can go to read about this project that you're working on?

- Derek, VE3XEC
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: SPAM: Re: SPAM: New on this

[echicken]

> some more knowledgeable people, the KISS TNC is responsible for:
>
> - Adding the Frame Check Sequence to outgoing packets, as well as for
> discarding incoming packets with an invalid FCS.
>
> - Adding start & stop flags to outgoing packets, stripping them from
> incoming packets
>
> - Interframe time fill (per http://www.tapr.org/pub_ax25.html#2.2.11)
>
> I suspect that the KISS TNC is also meant to take care of bit stuffing
> (per http://www.tapr.org/pub_ax25.html#2.2.6) to prevent erroneous
> flags being sent, but I haven't taken the time to confirm this yet.

I just realized that what I'd written might confuse matters slightly.
To be more specific, the KISS TNC is responsible for these things *in
addition to* the rest of its role as described in the specification
(waiting for silence before keying the transmitter, etc.)

- Derek, VE3XEC

Re: SPAM: Re: SPAM: New on this

[Marc Marí]

Hello echiken

I'll explain me a bit more, because now I am sure that I'm looking for
the wrong solution:

We are working on a CubeSat project in the University, which is a
project about creating a small satellite (10x10x10 cm). This small
size causes that the hardware has to be size-reduced and as least as
possible. This is the reason why, in the communications part,  we only
want to use what we have implemented now, and anything else: CC1101
chipset over RFC-1100H, and do everything else over software.

On the other hand, the Ground Station has its own requirements
(explained in the first email: TNC31 [or TNC7, but we are trying now
with 31], scrambling, etc.), and is GENSO compliant (is a project to
create a CubeSat worldwide network, or something like this, I have not
searched documentation about GENSO).

And now, we are searching the solution to create AX25 packets and
process them as if there was a TNC, and then ask CC1101 to send this
packages (this last thing works, the problem is that the data we send
now is not AX25 encoded, and the Ground Station doesn't understand
us). Linux AX25 seemed a good option, but before recompiling the
kernel, installing and configure, we wanted to know what it does
exactly, and implementing Linux AX.25, and then creating code to
scramble and all the other things seems oversized.

Do you know any solution for this?

I have to say too, as you asked, that we are not publishing data by
now, only a few thesis of the first people working on the project.

Thank you very much for your answers!



2013/4/5 echicken <echicken@bbs.electronicchicken.com>:
>> some more knowledgeable people, the KISS TNC is responsible for:
>>
>> - Adding the Frame Check Sequence to outgoing packets, as well as for
>> discarding incoming packets with an invalid FCS.
>>
>> - Adding start & stop flags to outgoing packets, stripping them from
>> incoming packets
>>
>> - Interframe time fill (per http://www.tapr.org/pub_ax25.html#2.2.11)
>>
>> I suspect that the KISS TNC is also meant to take care of bit stuffing
>> (per http://www.tapr.org/pub_ax25.html#2.2.6) to prevent erroneous
>> flags being sent, but I haven't taken the time to confirm this yet.
>
> I just realized that what I'd written might confuse matters slightly.
> To be more specific, the KISS TNC is responsible for these things *in
> addition to* the rest of its role as described in the specification
> (waiting for silence before keying the transmitter, etc.)
>
> - Derek, VE3XEC
> --
> To unsubscribe from this list: send the line "unsubscribe linux-hams" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: New on this

[Robin Gilks]

> Hello echiken
>
> I'll explain me a bit more, because now I am sure that I'm looking for
> the wrong solution:
>
> We are working on a CubeSat project in the University, which is a
> project about creating a small satellite (10x10x10 cm). This small
> size causes that the hardware has to be size-reduced and as least as
> possible. This is the reason why, in the communications part,  we only
> want to use what we have implemented now, and anything else: CC1101
> chipset over RFC-1100H, and do everything else over software.
>
> On the other hand, the Ground Station has its own requirements
> (explained in the first email: TNC31 [or TNC7, but we are trying now
> with 31], scrambling, etc.), and is GENSO compliant (is a project to
> create a CubeSat worldwide network, or something like this, I have not
> searched documentation about GENSO).
>
> And now, we are searching the solution to create AX25 packets and
> process them as if there was a TNC, and then ask CC1101 to send this
> packages (this last thing works, the problem is that the data we send
> now is not AX25 encoded, and the Ground Station doesn't understand
> us). Linux AX25 seemed a good option, but before recompiling the
> kernel, installing and configure, we wanted to know what it does
> exactly, and implementing Linux AX.25, and then creating code to
> scramble and all the other things seems oversized.
>
> Do you know any solution for this?
>
> I have to say too, as you asked, that we are not publishing data by
> now, only a few thesis of the first people working on the project.
>
> Thank you very much for your answers!

Might I suggest a few bits of code I've implemented over the last 15 years
or so?

Starting from more recent offerings, there is my fork of the BeRTOS
operating system at https://github.com/g8ecj/bertos which has an
implementation of all the HDLC and KISS protocols required for AX25. The
high level code is portable to pretty much any processor and the low level
physical interfaces are implemented for Arduino. Check out the HDLC branch
and try creating an example project based on either the KISS TNC or the
APRS TNC examples. The KISS implementation does all the p-persist
processing for multi-user channel access

If you're doing satellite stuff then 9k6 may be the way you'll be going in
which case there is also an example of interfacing to a g4xyw (g3ruh
compatible) 9k6 modem. The details for that you'll find on my website at
http://gilks.ath.cx/tvipug/v3.6/v3.6index.html

Another implementation of KISS can be found in my IPRI project from a few
years back. Also on my web sit at
http://gilks.ath.cx/tvipug/tnc/tncindex.html but written in assembler!!
Bigger AVR CPU were not available then! It might give you some ideas as it
takes SLIP (i.e. serial link IP) in and sends AX25 out - it handles all
the ARP processing, callsigns, digipeaters etc There are any number of
small IP stacks about that would be useful there, much easier to onward
route the data if its already IP, it just gets wrapped up in AX25 :)

Enjoy...


-- 
Robin Gilks zl3rob/g8ecj
Internet: g8ecj@gilks.org    http://www.gilks.org

Re: SPAM: Re: SPAM: New on this

[Richard Stearn]

Marc Marí wrote:
 > And now, we are searching the solution to create AX25 packets and
 > process them as if there was a TNC, and then ask CC1101 to send this
 > packages (this last thing works, the problem is that the data we send
 > now is not AX25 encoded, and the Ground Station doesn't understand
 > us). Linux AX25 seemed a good option, but before recompiling the
 > kernel, installing and configure, we wanted to know what it does
 > exactly, and implementing Linux AX.25, and then creating code to
 > scramble and all the other things seems oversized.
 >
 > Do you know any solution for this?

Marc

It is not clear from your original message which OS you are using.
You mention Linux AX.25, if you are using Linux as the OS then
this may be a route to a viable solution.

Enable "Amateur Radio AX.25 Level 2 protocol" and
"BAYCOM ser12 halfduplex driver for AX.25" driver.

The BAYCOM driver is a "bit banger".  It uses the "hdlcdrv" driver
to produce the HDLC frame to send and then the DTR, CTS & RTS
lines of standard RS232 for hardware IO:

DTR -> TXD
CTS -> RXD
RTS -> PTT

The original BAYCOM site has been shutdown for some years, however
you can find much related to the BAYCOM modem here:
http://www.nl3asd.tk/software/baycom/tcm3105.zip

and schematic of a BAYCOM modem here.
http://www.nl3asd.tk/software/baycom/tcm3105.zip

This will give you 1200bps half duplex.
Dependant on your hardware you may need to modify baycom_ser_hdx.c
to use different IO lines.

The above is _not_ a complete solution but may, if you are using
Linux, get you to the point of having TXD, RXD & PTT to connect
to you transceiver via some suitable modem.

-- 
73 de g1sog
     Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: SPAM: Re: SPAM: New on this

[Marc Marí]

We are using a Portux computer on a chip, with Debian and Linux.

I have to analize your solution, but I have to say that we are using
the CC1101 chipset to transmit, which is connected with SPI and which
transmits in 9600bps.

Even this, I'll look it carefully.

Thank you for your answer!

2013/4/5 Richard Stearn <richard@rns-stearn.demon.co.uk>:
> Marc Marí wrote:
>> And now, we are searching the solution to create AX25 packets and
>> process them as if there was a TNC, and then ask CC1101 to send this
>> packages (this last thing works, the problem is that the data we send
>> now is not AX25 encoded, and the Ground Station doesn't understand
>> us). Linux AX25 seemed a good option, but before recompiling the
>> kernel, installing and configure, we wanted to know what it does
>> exactly, and implementing Linux AX.25, and then creating code to
>> scramble and all the other things seems oversized.
>>
>> Do you know any solution for this?
>
> Marc
>
> It is not clear from your original message which OS you are using.
> You mention Linux AX.25, if you are using Linux as the OS then
> this may be a route to a viable solution.
>
> Enable "Amateur Radio AX.25 Level 2 protocol" and
> "BAYCOM ser12 halfduplex driver for AX.25" driver.
>
> The BAYCOM driver is a "bit banger".  It uses the "hdlcdrv" driver
> to produce the HDLC frame to send and then the DTR, CTS & RTS
> lines of standard RS232 for hardware IO:
>
> DTR -> TXD
> CTS -> RXD
> RTS -> PTT
>
> The original BAYCOM site has been shutdown for some years, however
> you can find much related to the BAYCOM modem here:
> http://www.nl3asd.tk/software/baycom/tcm3105.zip
>
> and schematic of a BAYCOM modem here.
> http://www.nl3asd.tk/software/baycom/tcm3105.zip
>
> This will give you 1200bps half duplex.
> Dependant on your hardware you may need to modify baycom_ser_hdx.c
> to use different IO lines.
>
> The above is _not_ a complete solution but may, if you are using
> Linux, get you to the point of having TXD, RXD & PTT to connect
> to you transceiver via some suitable modem.
>
> --
> 73 de g1sog
>     Richard
> --
> To unsubscribe from this list: send the line "unsubscribe linux-hams" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: SPAM: Re: SPAM: New on this

[Richard Stearn]

Marc Marí wrote:
> We are using a Portux computer on a chip, with Debian and Linux.
> 
> I have to analize your solution, but I have to say that we are using
> the CC1101 chipset to transmit, which is connected with SPI and which
> transmits in 9600bps.

In which case you will probably need to design and build a driver that
connects to the hdlcdrv for the HDLC packet assembly/disassembly in the
same way as the BAYCOM driver does and the Linux SPI driver for
bit transmit/receive via the CC1101.

-- 
73 de g1sog
	Richard

--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: New on this

[Marc Marí]

After a few discussion, we will finally develop our own code starting
with BeRTOS code, and probably with a few ideas of Baycom, in the
Linux Kernel.

Thank you very much for your answers!

2013/4/5 Robin Gilks <g8ecj@gilks.org>:
>
>> Hello echiken
>>
>> I'll explain me a bit more, because now I am sure that I'm looking for
>> the wrong solution:
>>
>> We are working on a CubeSat project in the University, which is a
>> project about creating a small satellite (10x10x10 cm). This small
>> size causes that the hardware has to be size-reduced and as least as
>> possible. This is the reason why, in the communications part,  we only
>> want to use what we have implemented now, and anything else: CC1101
>> chipset over RFC-1100H, and do everything else over software.
>>
>> On the other hand, the Ground Station has its own requirements
>> (explained in the first email: TNC31 [or TNC7, but we are trying now
>> with 31], scrambling, etc.), and is GENSO compliant (is a project to
>> create a CubeSat worldwide network, or something like this, I have not
>> searched documentation about GENSO).
>>
>> And now, we are searching the solution to create AX25 packets and
>> process them as if there was a TNC, and then ask CC1101 to send this
>> packages (this last thing works, the problem is that the data we send
>> now is not AX25 encoded, and the Ground Station doesn't understand
>> us). Linux AX25 seemed a good option, but before recompiling the
>> kernel, installing and configure, we wanted to know what it does
>> exactly, and implementing Linux AX.25, and then creating code to
>> scramble and all the other things seems oversized.
>>
>> Do you know any solution for this?
>>
>> I have to say too, as you asked, that we are not publishing data by
>> now, only a few thesis of the first people working on the project.
>>
>> Thank you very much for your answers!
>
> Might I suggest a few bits of code I've implemented over the last 15 years
> or so?
>
> Starting from more recent offerings, there is my fork of the BeRTOS
> operating system at https://github.com/g8ecj/bertos which has an
> implementation of all the HDLC and KISS protocols required for AX25. The
> high level code is portable to pretty much any processor and the low level
> physical interfaces are implemented for Arduino. Check out the HDLC branch
> and try creating an example project based on either the KISS TNC or the
> APRS TNC examples. The KISS implementation does all the p-persist
> processing for multi-user channel access
>
> If you're doing satellite stuff then 9k6 may be the way you'll be going in
> which case there is also an example of interfacing to a g4xyw (g3ruh
> compatible) 9k6 modem. The details for that you'll find on my website at
> http://gilks.ath.cx/tvipug/v3.6/v3.6index.html
>
> Another implementation of KISS can be found in my IPRI project from a few
> years back. Also on my web sit at
> http://gilks.ath.cx/tvipug/tnc/tncindex.html but written in assembler!!
> Bigger AVR CPU were not available then! It might give you some ideas as it
> takes SLIP (i.e. serial link IP) in and sends AX25 out - it handles all
> the ARP processing, callsigns, digipeaters etc There are any number of
> small IP stacks about that would be useful there, much easier to onward
> route the data if its already IP, it just gets wrapped up in AX25 :)
>
> Enjoy...
>
>
> --
> Robin Gilks zl3rob/g8ecj
> Internet: g8ecj@gilks.org    http://www.gilks.org
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-hams" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html